# Політика версійної розбіжності
> Максимально підтримувана версійна розбіжність між різними компонентами Kubernetes.
---
LLMS index: [llms.txt](/llms.txt)
---
Цей документ описує максимально підтримувану версійну розбіжність між різними компонентами Kubernetes. Конкретні інструменти розгортання кластерів можуть накладати додаткові обмеження на версійну розбіжність.
## Підтримувані версії {#supported-versions}
Версії Kubernetes позначаються як **x.y.z**, де **x** — основна версія, **y** — мінорна версія, а **z** — версія виправлення, згідно з термінологією [Семантичного Версіонування](https://semver.org/). Для отримання додаткової інформації дивіться [Kubernetes Release Versioning](https://git.k8s.io/sig-release/release-engineering/versioning.md#kubernetes-release-versioning).
Проєкт Kubernetes підтримує гілки випусків для останніх трьох мінорних випусків (1.36, 1.35, 1.34). Kubernetes 1.19 та новіші версії отримують [приблизно 1 рік підтримки виправлень](/releases/patch-releases/#support-period). Kubernetes 1.18 та старіші отримували приблизно 9 місяців підтримки виправлень.
Відповідні виправлення, включаючи виправлення безпеки, можуть бути перенесені на ці три гілки випусків залежно від серйозності та здійсненності. Випуски виправлення вирізаються з цих гілок на [регулярній основі](/releases/patch-releases/#cadence), а також додаткові термінові випуски, коли це необхідно.
Група [Менеджерів Релізів](/releases/release-managers/) володіє цим рішенням.
Для отримання додаткової інформації дивіться сторінку [Випуски виправлення](/releases/patch-releases/) Kubernetes.
## Підтримувана версійна розбіжність {#supported-version-skew}
### kube-apiserver
У [кластері з високою доступністю (HA)](/docs/setup/production-environment/tools/kubeadm/high-availability/), найновіші та найстаріші екземпляри `kube-apiserver` повинні бути в межах однієї мінорної версії.
Приклад:
* найновіший `kube-apiserver` має версію **1.36**
* інші екземпляри `kube-apiserver` підтримуються на версіях **1.36** та **1.35**
### kubelet
* `kubelet` не повинен бути новішим за `kube-apiserver`.
* `kubelet` може бути до трьох мінорних версій старішим за `kube-apiserver` (`kubelet` < 1.25 може бути не більше ніж на дві мінорні версії старішим за `kube-apiserver`).
Приклад:
* `kube-apiserver` має версію **1.36**
* `kubelet` підтримується на версіях **1.36**, **1.35**, **1.34** та **1.33**
Примітка:
Якщо існує версійна розбіжність між екземплярами kube-apiserver у HA кластері, це звужує допустимі версії kubelet.
Приклад:
* екземпляри `kube-apiserver` мають версії **1.36** та **1.35**
* `kubelet` підтримується на версіях **1.35**, **1.34**, та **1.33** (**1.36** не підтримується, оскільки це було б новішим за екземпляр `kube-apiserver` з версією **1.35**)
### 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.36**
* `kube-proxy` підтримується на версіях **1.36**, **1.35**, **1.34** та **1.33**
Примітка:
Якщо існує версійна розбіжність між екземплярами kube-apiserver у HA кластері, це звужує допустимі версії kube-proxy.
Приклад:
* екземпляри `kube-apiserver` мають версії **1.36** та **1.35**
* `kube-proxy` підтримується на версіях **1.35**, **1.34**, та **1.33** (**1.36** не підтримується, оскільки це було б новішим за екземпляр `kube-apiserver` з версією **1.35**)
### kube-controller-manager, kube-scheduler та cloud-controller-manager {#kube-controller-manager-kube-scheduler-and-cloud-controller-manager}
`kube-controller-manager`, `kube-scheduler` та `cloud-controller-manager` не повинні бути новішими за екземпляри `kube-apiserver`, з якими вони взаємодіють. Вони повинні відповідати мінорній версії `kube-apiserver`, але можуть бути до однієї мінорної версії старішими (для дозволу на живі оновлення).
Приклад:
* `kube-apiserver` має версію **1.36**
* `kube-controller-manager`, `kube-scheduler` та `cloud-controller-manager` підтримуються на версіях **1.36** та **1.35**
Примітка:
Якщо існує версійна розбіжність між екземплярами kube-apiserver у HA кластері, і ці компоненти можуть взаємодіяти з будь-яким екземпляром kube-apiserver у кластері (наприклад, через балансувальник навантаження), це звужує допустимі версії цих компонентів.
Приклад:
* екземпляри `kube-apiserver` мають версії **1.36** та **1.35**
* `kube-controller-manager`, `kube-scheduler` та `cloud-controller-manager` взаємодіють з балансувальником навантаження, який може направляти запити до будь-якого екземпляра `kube-apiserver`
* `kube-controller-manager`, `kube-scheduler` та `cloud-controller-manager` підтримуються на
версіях **1.35** (**1.36** не підтримується, оскільки це було б новішим за екземпляр `kube-apiserver` з версією **1.35**)
### kubectl
`kubectl` підтримується в межах однієї мінорної версії (старішої або новішої) від `kube-apiserver`.
Приклад:
* `kube-apiserver` має версію **1.36**
* `kubectl` підтримується на версіях **1.37**, **1.36**, та **1.35**
Примітка:
Якщо існує версійна розбіжність між екземплярами kube-apiserver у HA кластері, це звужує підтримувані версії kubectl.
Приклад:
* екземпляри `kube-apiserver` мають версії **1.36** та **1.35**
* `kubectl` підтримується на версіях **1.36** та **1.35** (інші версії будуть більше ніж на одну мінорну версію відрізнятися від одного з компонентів `kube-apiserver`)
## Підтримуваний порядок оновлення компонентів {#supported-component-upgrade-order}
Підтримувана версійна розбіжність між компонентами має наслідки для порядку, в якому компоненти повинні оновлюватися. Цей розділ описує порядок, у якому компоненти повинні оновлюватися для переходу поточного кластера з версії **1.35** до версії **1.36**.
За бажанням, при підготовці до оновлення, проєкт Kubernetes рекомендує зробити наступне для отримання максимальної кількості виправлень та усунення помилок під час оновлення:
* Переконайтеся, що компоненти знаходяться на найновішій версії виправлення вашої поточної мінорної версії.
* Оновіть компоненти до найновішої версії виправлення цільової мінорної версії.
Наприклад, якщо ви використовуєте версію 1.35, переконайтеся, що ви використовуєте найновішу версію виправлення. Потім оновіть до найновішої версії виправлення 1.36.
### kube-apiserver
Передумови:
* У кластері, що складається з одного екземпляру, наявний екземпляр `kube-apiserver` має версію **1.35**
* У HA кластері всі екземпляри `kube-apiserver` мають версії **1.35** або **1.36** (це забезпечує максимальну різницю в 1 мінорну версію між найстарішим та найновішим екземпляром `kube-apiserver`)
* Екземпляри `kube-controller-manager`, `kube-scheduler` та `cloud-controller-manager`, які взаємодіють з цим сервером, мають версію **1.35** (це забезпечує, що вони не новіші за поточну версію API сервера і знаходяться в межах 1 мінорної версії від нової версії API сервера)
* Екземпляри `kubelet` на всіх вузлах мають версії **1.35** або **1.34** (це забезпечує, що вони не новіші за поточну версію API сервера і знаходяться в межах 2 мінорних версій від нової версії API сервера)
* Зареєстровані вебхуки допуску здатні обробляти дані, які новий екземпляр `kube-apiserver` буде їм надсилати:
* Обʼєкти `ValidatingWebhookConfiguration` та `MutatingWebhookConfiguration` оновлені для включення будь-яких нових версій REST ресурсів, доданих у **1.36** (або використовують опцію [`matchPolicy: Equivalent`](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy), доступну у версії v1.15+)
* Вебхуки здатні обробляти будь-які нові версії REST ресурсів, які будуть їм надсилатися, і будь-які нові поля, додані до поточних версій у **1.36**
Оновіть `kube-apiserver` до **1.36**
Примітка:
Політики проєкту щодо
застарівання API та
рекомендацій щодо змін API вимагають, щоб
kube-apiserver не пропускав мінорні версії під час оновлення, навіть у кластерах, що складаються з одного екземпляру.
Примітка:
Перед виконанням мінорного оновлення
kubelet,
виселіть Podʼи з цього вузла. Оновлення
kubelet на місці до іншої мінорної версії не підтримується.
Попередження:
Запуск кластера з екземплярами kubelet, які постійно знаходяться на три мінорні версії позаду kube-apiserver, означає, що вони повинні бути оновлені перед оновленням панелі управління.
### kube-proxy
Передумови:
* Екземпляри `kube-apiserver`, з якими `kube-proxy` взаємодіє, мають версію **1.36**
За бажанням, оновіть екземпляри `kube-proxy` до **1.36** (або їх можна залишити на версіях **1.35**, **1.34**, або **1.33**)
Попередження:
Запуск кластера з екземплярами kube-proxy, які постійно знаходяться на три мінорні версії позаду kube-apiserver, означає, що вони повинні бути оновлені перед оновленням панелі управління.