Політика версійної розбіжності
Цей документ описує максимально підтримувану версійну розбіжність між різними компонентами Kubernetes. Конкретні інструменти розгортання кластерів можуть накладати додаткові обмеження на версійну розбіжність.
Підтримувані версії
Версії Kubernetes позначаються як x.y.z, де x — основна версія, y — мінорна версія, а z — патч-версія, згідно з термінологією Семантичного Версіонування. Для отримання додаткової інформації дивіться Kubernetes Release Versioning.
Проєкт Kubernetes підтримує гілки випусків для останніх трьох мінорних випусків (1.31, 1.30, 1.29). Kubernetes 1.19 та новіші версії отримують приблизно 1 рік патч-підтримки. Kubernetes 1.18 та старіші отримували приблизно 9 місяців патч-підтримки.
Відповідні виправлення, включаючи виправлення безпеки, можуть бути перенесені на ці три гілки випусків залежно від серйозності та здійсненності. Патч-випуски вирізаються з цих гілок на регулярній основі, а також додаткові термінові випуски, коли це необхідно.
Група Менеджерів Релізів володіє цим рішенням.
Для отримання додаткової інформації дивіться сторінку Патч-випуски Kubernetes.
Підтримувана версійна розбіжність
kube-apiserver
У кластері з високою доступністю (HA), найновіші та найстаріші екземпляри kube-apiserver
повинні бути в межах однієї мінорної версії.
Приклад:
- найновіший
kube-apiserver
має версію 1.31 - інші екземпляри
kube-apiserver
підтримуються на версіях 1.31 та 1.30
kubelet
kubelet
не повинен бути новішим заkube-apiserver
.kubelet
може бути до трьох мінорних версій старішим заkube-apiserver
(kubelet
< 1.25 може бути не більше ніж на дві мінорні версії старішим заkube-apiserver
).
Приклад:
kube-apiserver
має версію 1.31kubelet
підтримується на версіях 1.31, 1.30, 1.29 та 1.28
Примітка:
Якщо існує версійна розбіжність між екземплярамиkube-apiserver
у HA кластері, це звужує допустимі версії kubelet
.Приклад:
- екземпляри
kube-apiserver
мають версії 1.31 та 1.30 kubelet
підтримується на версіях 1.30, 1.29, та 1.28 (1.31 не підтримується, оскільки це було б новішим за екземплярkube-apiserver
з версією 1.30)
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.31kube-proxy
підтримується на версіях 1.31, 1.30, 1.29 та 1.28
Примітка:
Якщо існує версійна розбіжність між екземплярамиkube-apiserver
у HA кластері, це звужує допустимі версії kube-proxy
.Приклад:
- екземпляри
kube-apiserver
мають версії 1.31 та 1.30 kube-proxy
підтримується на версіях 1.30, 1.29, та 1.28 (1.31 не підтримується, оскільки це було б новішим за екземплярkube-apiserver
з версією 1.30)
kube-controller-manager, kube-scheduler та cloud-controller-manager
kube-controller-manager
, kube-scheduler
та cloud-controller-manager
не повинні бути новішими за екземпляри kube-apiserver
, з якими вони взаємодіють. Вони повинні відповідати мінорній версії kube-apiserver
, але можуть бути до однієї мінорної версії старішими (для дозволу на живі оновлення).
Приклад:
kube-apiserver
має версію 1.31kube-controller-manager
,kube-scheduler
таcloud-controller-manager
підтримуються на версіях 1.31 та 1.30
Примітка:
Якщо існує версійна розбіжність між екземплярамиkube-apiserver
у HA кластері, і ці компоненти можуть взаємодіяти з будь-яким екземпляром kube-apiserver
у кластері (наприклад, через балансувальник навантаження), це звужує допустимі версії цих компонентів.Приклад:
- екземпляри
kube-apiserver
мають версії 1.31 та 1.30 kube-controller-manager
,kube-scheduler
таcloud-controller-manager
взаємодіють з балансувальником навантаження, який може направляти запити до будь-якого екземпляраkube-apiserver
kube-controller-manager
,kube-scheduler
таcloud-controller-manager
підтримуються на версіях 1.30 (1.31 не підтримується, оскільки це було б новішим за екземплярkube-apiserver
з версією 1.30)
kubectl
kubectl
підтримується в межах однієї мінорної версії (старішої або новішої) від kube-apiserver
.
Приклад:
kube-apiserver
має версію 1.31kubectl
підтримується на версіях 1.32, 1.31, та 1.30
Примітка:
Якщо існує версійна розбіжність між екземплярамиkube-apiserver
у HA кластері, це звужує підтримувані версії kubectl
.Приклад:
- екземпляри
kube-apiserver
мають версії 1.31 та 1.30 kubectl
підтримується на версіях 1.31 та 1.30 (інші версії будуть більше ніж на одну мінорну версію відрізнятися від одного з компонентівkube-apiserver
)
Підтримуваний порядок оновлення компонентів
Підтримувана версійна розбіжність між компонентами має наслідки для порядку, в якому компоненти повинні оновлюватися. Цей розділ описує порядок, у якому компоненти повинні оновлюватися для переходу поточного кластера з версії 1.30 до версії 1.31.
За бажанням, при підготовці до оновлення, проєкт Kubernetes рекомендує зробити наступне для отримання максимальної кількості виправлень та усунення помилок під час оновлення:
- Переконайтеся, що компоненти знаходяться на найновішій патч-версії вашої поточної мінорної версії.
- Оновіть компоненти до найновішої патч-версії цільової мінорної версії.
Наприклад, якщо ви використовуєте версію 1.30, переконайтеся, що ви використовуєте найновішу патч-версію. Потім оновіть до найновішої патч-версії 1.31.
kube-apiserver
Передумови:
- У кластері, що складається з одного екземпляру, наявний екземпляр
kube-apiserver
має версію 1.30 - У HA кластері всі екземпляри
kube-apiserver
мають версії 1.30 або 1.31 (це забезпечує максимальну різницю в 1 мінорну версію між найстарішим та найновішим екземпляромkube-apiserver
) - Екземпляри
kube-controller-manager
,kube-scheduler
таcloud-controller-manager
, які взаємодіють з цим сервером, мають версію 1.30 (це забезпечує, що вони не новіші за поточну версію API сервера і знаходяться в межах 1 мінорної версії від нової версії API сервера) - Екземпляри
kubelet
на всіх вузлах мають версії 1.30 або 1.29 (це забезпечує, що вони не новіші за поточну версію API сервера і знаходяться в межах 2 мінорних версій від нової версії API сервера) - Зареєстровані вебхуки допуску здатні обробляти дані, які новий екземпляр
kube-apiserver
буде їм надсилати:- Обʼєкти
ValidatingWebhookConfiguration
таMutatingWebhookConfiguration
оновлені для включення будь-яких нових версій REST ресурсів, доданих у 1.31 (або використовують опціюmatchPolicy: Equivalent
, доступну у версії v1.15+) - Вебхуки здатні обробляти будь-які нові версії REST ресурсів, які будуть їм надсилатися, і будь-які нові поля, додані до поточних версій у 1.31
- Обʼєкти
Оновіть kube-apiserver
до 1.31
Примітка:
Політики проєкту щодо застарівання API та рекомендацій щодо змін API вимагають, щобkube-apiserver
не пропускав мінорні версії під час оновлення, навіть у кластерах, що складаються з одного екземпляру.kube-controller-manager, kube-scheduler та cloud-controller-manager
Передумови:
- Екземпляри
kube-apiserver
, з якими ці компоненти взаємодіють, мають версію 1.31 (у HA кластерах, в яких ці компоненти керування можуть взаємодіяти з будь-яким екземпляромkube-apiserver
у кластері, всі екземпляриkube-apiserver
повинні бути оновлені перед оновленням цих компонентів)
Оновіть kube-controller-manager
, kube-scheduler
та cloud-controller-manager
до 1.31. Немає встановленого порядку оновлення між kube-controller-manager
, kube-scheduler
та cloud-controller-manager
. Ви можете оновити ці компоненти в будь-якому порядку або навіть одночасно.
kubelet
Передумови:
- Екземпляри
kube-apiserver
, з якимиkubelet
взаємодіє, мають версію 1.31
За бажанням, оновіть екземпляри kubelet
до 1.31 (або їх можна залишити на версіях 1.30, 1.29, або 1.28)
Примітка:
Перед виконанням мінорного оновленняkubelet
, виселіть Podʼи з цього вузла. Оновлення kubelet
на місці до іншої мінорної версії не підтримується.Попередження:
Запуск кластера з екземплярамиkubelet
, які постійно знаходяться на три мінорні версії позаду kube-apiserver
, означає, що вони повинні бути оновлені перед оновленням контрольної площини.kube-proxy
Передумови:
- Екземпляри
kube-apiserver
, з якимиkube-proxy
взаємодіє, мають версію 1.31
За бажанням, оновіть екземпляри kube-proxy
до 1.31 (або їх можна залишити на версіях 1.30, 1.29, або 1.28)
Попередження:
Запуск кластера з екземплярамиkube-proxy
, які постійно знаходяться на три мінорні версії позаду kube-apiserver
, означає, що вони повинні бути оновлені перед оновленням панелі управління.