Політика версійної розбіжності

Цей документ описує максимально підтримувану версійну розбіжність між різними компонентами Kubernetes. Конкретні інструменти розгортання кластерів можуть накладати додаткові обмеження на версійну розбіжність.

Підтримувані версії

Версії Kubernetes позначаються як x.y.z, де x — основна версія, y — мінорна версія, а z — патч-версія, згідно з термінологією Семантичного Версіонування. Для отримання додаткової інформації дивіться Kubernetes Release Versioning.

Проєкт Kubernetes підтримує гілки випусків для останніх трьох мінорних випусків (1.30, 1.29, 1.28). Kubernetes 1.19 та новіші версії отримують приблизно 1 рік патч-підтримки. Kubernetes 1.18 та старіші отримували приблизно 9 місяців патч-підтримки.

Відповідні виправлення, включаючи виправлення безпеки, можуть бути перенесені на ці три гілки випусків залежно від серйозності та здійсненності. Патч-випуски вирізаються з цих гілок на регулярній основі, а також додаткові термінові випуски, коли це необхідно.

Група Менеджерів Релізів володіє цим рішенням.

Для отримання додаткової інформації дивіться сторінку Патч-випуски Kubernetes.

Підтримувана версійне розбіжність

kube-apiserver

У кластері з високою доступністю (HA), найновіші та найстаріші екземпляри kube-apiserver повинні бути в межах однієї мінорної версії.

Приклад:

• найновіший kube-apiserver має версію 1.30
• інші екземпляри kube-apiserver підтримуються на версіях 1.30 та 1.29

kubelet

• kubelet не повинен бути новішим за kube-apiserver.
• kubelet може бути до трьох мінорних версій старішим за kube-apiserver (kubelet < 1.25 може бути не більше ніж на дві мінорні версії старішим за kube-apiserver).

Приклад:

• kube-apiserver має версію 1.30
• kubelet підтримується на версіях 1.30, 1.29, 1.28 та 1.27

Приклад:

• екземпляри kube-apiserver мають версії 1.30 та 1.29
• kubelet підтримується на версіях 1.29, 1.28, та 1.27 (1.30 не підтримується, оскільки це було б новішим за екземпляр kube-apiserver з версією 1.29)

kube-proxy

• kube-proxy не повинен бути новішим за kube-apiserver.
• kube-proxy може бути до трьох мінорних версій старішим за kube-apiserver (kube-proxy < 1.25 може бути не більше ніж на дві мінорні версії старішим за kube-apiserver).
• kube-proxy може бути до трьох мінорних версій старішим або новішим за екземпляр kubelet, з яким він працює (kube-proxy < 1.25 може бути не більше ніж на дві мінорні версії старішим або новішим за екземпляр kubelet, з яким він працює).

Приклад:

• kube-apiserver має версію 1.30
• kube-proxy підтримується на версіях 1.30, 1.29, 1.28 та 1.27

Приклад:

• екземпляри kube-apiserver мають версії 1.30 та 1.29
• kube-proxy підтримується на версіях 1.29, 1.28, та 1.27 (1.30 не підтримується, оскільки це було б новішим за екземпляр kube-apiserver з версією 1.29)

kube-controller-manager, kube-scheduler та cloud-controller-manager

kube-controller-manager, kube-scheduler та cloud-controller-manager не повинні бути новішими за екземпляри kube-apiserver, з якими вони взаємодіють. Вони повинні відповідати мінорній версії kube-apiserver, але можуть бути до однієї мінорної версії старішими (для дозволу на живі оновлення).

Приклад:

• kube-apiserver має версію 1.30
• kube-controller-manager, kube-scheduler та cloud-controller-manager підтримуються на версіях 1.30 та 1.29

Приклад:

• екземпляри kube-apiserver мають версії 1.30 та 1.29
• kube-controller-manager, kube-scheduler та cloud-controller-manager взаємодіють з балансувальником навантаження, який може направляти запити до будь-якого екземпляра kube-apiserver
• kube-controller-manager, kube-scheduler та cloud-controller-manager підтримуються на версіях 1.29 (1.30 не підтримується, оскільки це було б новішим за екземпляр kube-apiserver з версією 1.29)

kubectl

kubectl підтримується в межах однієї мінорної версії (старішої або новішої) від kube-apiserver.

Приклад:

• kube-apiserver має версію 1.30
• kubectl підтримується на версіях 1.31, 1.30, та 1.29

Приклад:

• екземпляри kube-apiserver мають версії 1.30 та 1.29
• kubectl підтримується на версіях 1.30 та 1.29 (інші версії будуть більше ніж на одну мінорну версію відрізнятися від одного з компонентів kube-apiserver)

Підтримуваний порядок оновлення компонентів

Підтримувана версійна розбіжність між компонентами має наслідки для порядку, в якому компоненти повинні оновлюватися. Цей розділ описує порядок, у якому компоненти повинні оновлюватися для переходу поточного кластера з версії 1.29 до версії 1.30.

За бажанням, при підготовці до оновлення, проєкт Kubernetes рекомендує зробити наступне для отримання максимальної кількості виправлень та усунення помилок під час оновлення:

• Переконайтеся, що компоненти знаходяться на найновішій патч-версії вашої поточної мінорної версії.
• Оновіть компоненти до найновішої патч-версії цільової мінорної версії.

Наприклад, якщо ви використовуєте версію 1.29, переконайтеся, що ви використовуєте найновішу патч-версію. Потім оновіть до найновішої патч-версії 1.30.

kube-apiserver

Передумови:

• У кластері, що складається з одного екземпляру, наявний екземпляр kube-apiserver має версію 1.29
• У HA кластері всі екземпляри kube-apiserver мають версії 1.29 або 1.30 (це забезпечує максимальну різницю в 1 мінорну версію між найстарішим та найновішим екземпляром kube-apiserver)
• Екземпляри kube-controller-manager, kube-scheduler та cloud-controller-manager, які взаємодіють з цим сервером, мають версію 1.29 (це забезпечує, що вони не новіші за поточну версію API сервера і знаходяться в межах 1 мінорної версії від нової версії API сервера)
• Екземпляри kubelet на всіх вузлах мають версії 1.29 або 1.28 (це забезпечує, що вони не новіші за поточну версію API сервера і знаходяться в межах 2 мінорних версій від нової версії API сервера)
• Зареєстровані вебхуки допуску здатні обробляти дані, які новий екземпляр kube-apiserver буде їм надсилати:
  • Обʼєкти ValidatingWebhookConfiguration та MutatingWebhookConfiguration оновлені для включення будь-яких нових версій REST ресурсів, доданих у 1.30 (або використовують опцію matchPolicy: Equivalent, доступну у версії v1.15+)
  • Вебхуки здатні обробляти будь-які нові версії REST ресурсів, які будуть їм надсилатися, і будь-які нові поля, додані до поточних версій у 1.30

Оновіть kube-apiserver до 1.30

kube-controller-manager, kube-scheduler та cloud-controller-manager

Передумови:

• Екземпляри kube-apiserver, з якими ці компоненти взаємодіють, мають версію 1.30 (у HA кластерах, в яких ці компоненти керування можуть взаємодіяти з будь-яким екземпляром kube-apiserver у кластері, всі екземпляри kube-apiserver повинні бути оновлені перед оновленням цих компонентів)

Оновіть kube-controller-manager, kube-scheduler та cloud-controller-manager до 1.30. Немає встановленого порядку оновлення між kube-controller-manager, kube-scheduler та cloud-controller-manager. Ви можете оновити ці компоненти в будь-якому порядку або навіть одночасно.

kubelet

Передумови:

• Екземпляри kube-apiserver, з якими kubelet взаємодіє, мають версію 1.30

За бажанням, оновіть екземпляри kubelet до 1.30 (або їх можна залишити на версіях 1.29, 1.28, або 1.27)

kube-proxy

Передумови:

• Екземпляри kube-apiserver, з якими kube-proxy взаємодіє, мають версію 1.30

За бажанням, оновіть екземпляри kube-proxy до 1.30 (або їх можна залишити на версіях 1.29, 1.28, або 1.27)