Проєкт Kubernetes підтримує гілки випусків для трьох останніх мінорних випусків (1.32, 1.31, 1.30). Kubernetes 1.19 та новіші отримують приблизно 1 рік патчі підтримки. Kubernetes 1.18 та старіші отримували патчі приблизно впродовж 9 місяців.
Версії Kubernetes зазначаються у вигляді x.y.z, де
Kubernetes надає бінарні файли для кожного компонента, а також стандартний набір клієнтських застосунків для початкового завантаження або взаємодії з кластером. Компоненти, такі як API-сервер, здатні працювати всередині контейнерних образів в кластері. Ці компоненти також постачаються в контейнерних образах як частина офіційного процесу випуску. Всі бінарні файли, а також контейнерні образи доступні для різних операційних систем та архітектур апаратного забезпечення.
kubectl
Командний рядок Kubernetes, kubectl, дозволяє виконувати команди в кластерах Kubernetes.
Ви можете використовувати kubectl для розгортання застосунків, інспектування та керування ресурсами кластера, а також перегляду логів. Для отримання додаткової інформації, включаючи повний список операцій kubectl, дивіться довідкову документацію kubectl.
kubectl можна встановити на різних платформах Linux, macOS і Windows. Знайдіть вашу операційну систему нижче.
Всі контейнерні образи Kubernetes розміщені в реєстрі контейнерних образів registry.k8s.io.
Контейнерний образ
Підтримувані архітектури
registry.k8s.io/kube-apiserver:v1.32.0
amd64, arm, arm64, ppc64le, s390x
registry.k8s.io/kube-controller-manager:v1.32.0
amd64, arm, arm64, ppc64le, s390x
registry.k8s.io/kube-proxy:v1.32.0
amd64, arm, arm64, ppc64le, s390x
registry.k8s.io/kube-scheduler:v1.32.0
amd64, arm, arm64, ppc64le, s390x
registry.k8s.io/conformance:v1.32.0
amd64, arm, arm64, ppc64le, s390x
Архітектури контейнерних образів
Всі контейнерні образи доступні для кількох архітектур, тоді як середовище виконання контейнерів має вибрати правильну архітектуру на основі базової платформи. Також можна витягнути образ для конкретної архітектури, додавши суфікс до імені контейнерного образу, наприклад registry.k8s.io/kube-apiserver-arm64:v1.32.0.
Підписи контейнерних образів
FEATURE STATE:Kubernetes v1.26 [beta]
Для Kubernetes v1.32, контейнерні образи підписуються за допомогою sigstore підписів:
Примітка:
Підписи контейнерних образів sigstore наразі не збігаються між різними географічними положеннями. Додаткова інформація про цю проблему доступна у відповідному GitHub issue.
Проєкт Kubernetes публікує список підписаних контейнерних образів Kubernetes у форматі SPDX 2.3. Ви можете отримати цей список за допомогою:
Якщо ви витягуєте образ контейнера для певної архітектури, то цей образ для однієї архітектури
підписаний так само як і мультиархітектурні списки маніфестів.
Бінарні файли
Ви можете знайти посилання на завантаження компонентів Kubernetes (та їх контрольні суми) у файлах CHANGELOG.
Або ж, скористайтесь downloadkubernetes.com для вибору за версією та архітектурою.
Ви можете знайти посилання для завантаження компонентів версії v1.32 Kubernetes (разом з їх контрольними сумами) нижче.
Щоб отримати доступ до завантажень для попередніх підтримуваних версій, перейдіть за відповідним посиланням в
документації для попередніх версій або скористайтеся downloadkubernetes.com.
Примітка:
Для завантаження старіших патч-версій компонентів версії v1.32 Kubernetes (разом з їх контрольними сумами),
дивіться файл CHANGELOG.
Розклад та контактна інформація для патч-випусків Kubernetes.
Для загальної інформації про цикл випусків Kubernetes, дивіться опис процесу випуску.
Періодичність
Типова періодичність патч-випусків — щомісяця. Зазвичай вона трохи швидша (1-2 тижні) для перших патч-випусків після 1.X мінорного випуску. Критичні виправлення можуть призвести до негайного випуску поза звичайною періодичністю. Ми також намагаємося не робити випуски під час основних святкових періодів.
Контакт
Дивіться сторінку Менеджери Випусків для отримання повних контактних даних команди патч-випусків.
Дайте нам хоча б один робочий день на відповідь — ми можемо бути в іншому часовому поясі!
Між випусками команда переглядає вхідні запити на cherry pick щотижня. Команда буде звʼязуватися з вами через GitHub PR, канали SIG у Slack, прямі повідомлення у Slack та email якщо є питання щодо PR.
Cherry picks повинні бути готові до злиття у GitHub з правильними мітками (наприклад, approved, lgtm, release-note) та успішними CI тестами до граничного терміну для cherry pick. Зазвичай це за два дні до цільового випуску, але може бути й більше. Раніша готовність PR краще, оскільки нам потрібен час для отримання сигналу CI після злиття ваших cherry picks перед фактичним випуском.
Cherry pick PR, які не відповідають критеріям злиття, будуть перенесені та додані для наступного патч-випуску.
Період підтримки
Відповідно до річної підтримки KEP, спільнота Kubernetes підтримуватиме активні серії патч-випусків протягом приблизно чотирнадцяти (14) місяців.
Перші дванадцять місяців цього терміну вважатимуться стандартним періодом.
Наприкінці дванадцятого місяця станеться наступне:
Серія патч-випусків перейде в режим обслуговування
Протягом двомісячного періоду обслуговування Менеджери Випусків можуть робити додаткові випуски обслуговування для розвʼязання наступних проблем:
CVE (за порадою Security Response Committee)
проблеми із залежностями (включаючи оновлення базових образів)
критичні проблеми основних компонентів
Наприкінці двомісячного періоду обслуговування серія патч-випусків вважатиметься завершеною (EOL) і cherry picks до відповідної гілки будуть закриті незабаром після цього.
Зверніть увагу, що 28-е число місяця було обрано як цільові дати для режиму обслуговування та EOL для зручності (кожен місяць має це число).
Майбутні щомісячні випуски
Часові рамки можуть змінюватися залежно від важливості виправлень, але для полегшення планування ми орієнтуватимемося на наступні щомісячні точки випуску. Незаплановані, критичні випуски можуть також відбуватися у проміжках між ними.
Monthly Patch Release
Строк Cherry Pick
Заплановано
січня 2025
лютого 2025
березня 2025
Детальна історія випусків для активних гілок
1.32
Наступний патч 1.32.1.
1.32 переходить в режим технічного обслуговування , кінець життєвого циклу — .
Патч
Строк Cherry Pick
Заплановано
Примітка
1.32.0
-
1.31
Наступний патч 1.31.5.
1.31 переходить в режим технічного обслуговування , кінець життєвого циклу — .
Патч
Строк Cherry Pick
Заплановано
Примітка
1.31.4
1.31.3
1.31.2
1.31.1
1.31.0
-
1.30
Наступний патч 1.30.9.
1.30 переходить в режим технічного обслуговування , кінець життєвого циклу — .
Патч
Строк Cherry Pick
Заплановано
Примітка
1.30.8
1.30.7
1.30.6
1.30.5
1.30.4
1.30.3
1.30.2
1.30.1
1.30.0
-
1.29
1.29 переходить в режим технічного обслуговування , кінець життєвого циклу — .
Патч
Строк Cherry Pick
Заплановано
Примітка
1.29.12
1.29.11
1.29.10
1.29.9
1.29.8
1.29.7
1.29.6
1.29.5
1.29.4
1.29.3
1.29.2
1.29.1
1.29.0
-
Історія неактивних гілок
Ці випуски більше не підтримуються.
Мінорна версія
Остаточний патч-випуск
Завершення життєвого циклу
Примітка
1.28
1.28.15
1.27
1.27.16
1.26
1.26.15
1.26.15 was released in March 2024 (after the EOL date) to pick up a new version of Go to address several Go CVEs
1.25
1.25.16
1.25.16 was released in November 2023 (after the EOL date) to fix CVE-2023-5528
1.24
1.24.17
1.24.17 was released in August 2023 (after the EOL date) to fix CVE-2023-3676 and CVE-2023-3955
1.23
1.23.17
1.22
1.22.17
1.22.17 was released in December 2022 (after the EOL date) to backport registry changes and fix two critical issues.
1.21
1.21.14
1.20
1.20.15
1.19
1.19.16
1.18
1.18.20
Created to solve regression introduced in 1.18.19
1.17
1.17.17
1.16
1.16.15
1.15
1.15.12
1.14
1.14.10
1.13
1.13.12
1.12
1.12.10
1.11
1.11.10
1.10
1.10.13
1.9
1.9.11
1.8
1.8.15
1.7
1.7.16
1.6
1.6.13
1.5
1.5.8
1.4
1.4.12
1.3
1.3.10
1.2
1.2.7
3 - Менеджери випусків
"Менеджери Випусків" — це загальний термін, що охоплює групу учасників Kubernetes, відповідальних за підтримку гілок випусків та створення випусків, використовуючи інструменти, надані SIG Release.
Деяка інформація про випуски підлягає закритості, і ми визначили політику щодо того, як ці обмеження встановлюються. Будь ласка, зверніться до Політики закритості за для безпеки для отримання додаткової інформації.
Довідники
Примітка: Довідники для Команди Патч-Випусків та Менеджерів Гілок будуть уніфіковані пізніше.
Щоб стати Менеджером Випусків, необхідно спочатку бути Асистентом Менеджера Випусків. Асистенти переходять до ролі Менеджера Випусків, активно працюючи над випусками протягом кількох циклів та:
демонструючи готовність до лідерства
працюючи разом з Менеджерами Випусків над патчами, щоб у результаті провести випуск самостійно
оскільки випуски мають обмежувальну функцію, ми також розглядаємо значні внески у просування образів та інші основні завдання Інженерії Випусків
ставлячи питання про роботу Асистентів, пропонуючи покращення, збираючи відгуки та впроваджуючи зміни
будучи надійними та відповідальними
займаючись складними завданнями, які вимагають доступу та привілеїв рівня Менеджера Випусків для завершення
Асистенти менеджерів випусків
Асистенти Менеджерів Випусків є стажерами Менеджерів Випусків, раніше відомими як тіні Менеджерів Випусків. Вони відповідають за:
Роботу над патч-випусками, перегляд cherry picks
Внесок у k/release: оновлення залежностей та ознайомлення з кодовою базою
Внесок у документацію: підтримку довідників, забезпечення документування процесів випуску
За допомогою Менеджера Випусків: роботу з Командою Випуску протягом циклу випуску та проведення випусків Kubernetes
Пошук можливостей для допомоги у пріоритизації та комунікації
Надсилання попередніх оголошень та оновлень про патч-випуски
Учасники можуть стати Асистентами, демонструючи наступне:
послідовну участь, включаючи 6-12 місяців активної роботи, повʼязаної з інженерною роботою, повʼязаною з випусками
досвід виконання ролі технічного лідера у Команді Випуску протягом циклу випуску
цей досвід надає міцну базу для розуміння роботи SIG Release загалом — включаючи наші очікування щодо технічних навичок, комунікацій/відповідальності та надійності
роботу над завданнями k/release, що покращують взаємодію з Testgrid, очищення бібліотек тощо
ці зусилля вимагають взаємодії та співпраці з Менеджерами Випусків та Асистентами
Лідери SIG Release
Голови та Технічні Лідери SIG Release відповідають за:
Управління SIG Release
Проведення сесій обміну знаннями для Менеджерів Випусків та Асистентів
Наставництво з питань лідерства та пріоритизації
Вони згадуються тут, оскільки є власниками різних каналів спілкування та груп дозволів (команди GitHub, доступ GCP) для кожної ролі. Таким чином, вони є високопривілейованими членами спільноти та мають доступ до деяких приватних комунікацій, які іноді можуть стосуватися розголошення безпеки Kubernetes.
Нотатки про випуски можна знайти, переглянувши Changelog, який відповідає вашій версії Kubernetes. Перегляньте changelog для 1.32 на GitHub.
Або, нотатки про випуски можна шукати та фільтрувати онлайн на: relnotes.k8s.io. Перегляньте відфільтровані нотатки про випуски для 1.32 на relnotes.k8s.io.
5 - Політика версійної розбіжності
Максимально підтримувана версійна розбіжність між різними компонентами Kubernetes.
Цей документ описує максимально підтримувану версійну розбіжність між різними компонентами Kubernetes. Конкретні інструменти розгортання кластерів можуть накладати додаткові обмеження на версійну розбіжність.
Підтримувані версії
Версії Kubernetes позначаються як x.y.z, де x — основна версія, y — мінорна версія, а z — патч-версія, згідно з термінологією Семантичного Версіонування. Для отримання додаткової інформації дивіться Kubernetes Release Versioning.
Проєкт Kubernetes підтримує гілки випусків для останніх трьох мінорних випусків (1.32, 1.31, 1.30). Kubernetes 1.19 та новіші версії отримують приблизно 1 рік патч-підтримки. Kubernetes 1.18 та старіші отримували приблизно 9 місяців патч-підтримки.
Відповідні виправлення, включаючи виправлення безпеки, можуть бути перенесені на ці три гілки випусків залежно від серйозності та здійсненності. Патч-випуски вирізаються з цих гілок на регулярній основі, а також додаткові термінові випуски, коли це необхідно.
інші екземпляри kube-apiserver підтримуються на версіях 1.32 та 1.31
kubelet
kubelet не повинен бути новішим за kube-apiserver.
kubelet може бути до трьох мінорних версій старішим за kube-apiserver (kubelet < 1.25 може бути не більше ніж на дві мінорні версії старішим за kube-apiserver).
Приклад:
kube-apiserver має версію 1.32
kubelet підтримується на версіях 1.32, 1.31, 1.30 та 1.29
Примітка:
Якщо існує версійна розбіжність між екземплярами kube-apiserver у HA кластері, це звужує допустимі версії kubelet.
Приклад:
екземпляри kube-apiserver мають версії 1.32 та 1.31
kubelet підтримується на версіях 1.31, 1.30, та 1.29 (1.32 не підтримується, оскільки це було б новішим за екземпляр kube-apiserver з версією 1.31)
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.32
kube-proxy підтримується на версіях 1.32, 1.31, 1.30 та 1.29
Примітка:
Якщо існує версійна розбіжність між екземплярами kube-apiserver у HA кластері, це звужує допустимі версії kube-proxy.
Приклад:
екземпляри kube-apiserver мають версії 1.32 та 1.31
kube-proxy підтримується на версіях 1.31, 1.30, та 1.29 (1.32 не підтримується, оскільки це було б новішим за екземпляр kube-apiserver з версією 1.31)
kube-controller-manager, kube-scheduler та cloud-controller-manager
kube-controller-manager, kube-scheduler та cloud-controller-manager не повинні бути новішими за екземпляри kube-apiserver, з якими вони взаємодіють. Вони повинні відповідати мінорній версії kube-apiserver, але можуть бути до однієї мінорної версії старішими (для дозволу на живі оновлення).
Приклад:
kube-apiserver має версію 1.32
kube-controller-manager, kube-scheduler та cloud-controller-manager підтримуються на версіях 1.32 та 1.31
Примітка:
Якщо існує версійна розбіжність між екземплярами kube-apiserver у HA кластері, і ці компоненти можуть взаємодіяти з будь-яким екземпляром kube-apiserver у кластері (наприклад, через балансувальник навантаження), це звужує допустимі версії цих компонентів.
Приклад:
екземпляри kube-apiserver мають версії 1.32 та 1.31
kube-controller-manager, kube-scheduler та cloud-controller-manager взаємодіють з балансувальником навантаження, який може направляти запити до будь-якого екземпляра kube-apiserver
kube-controller-manager, kube-scheduler та cloud-controller-manager підтримуються на
версіях 1.31 (1.32 не підтримується, оскільки це було б новішим за екземпляр kube-apiserver з версією 1.31)
kubectl
kubectl підтримується в межах однієї мінорної версії (старішої або новішої) від kube-apiserver.
Приклад:
kube-apiserver має версію 1.32
kubectl підтримується на версіях 1.33, 1.32, та 1.31
Примітка:
Якщо існує версійна розбіжність між екземплярами kube-apiserver у HA кластері, це звужує підтримувані версії kubectl.
Приклад:
екземпляри kube-apiserver мають версії 1.32 та 1.31
kubectl підтримується на версіях 1.32 та 1.31 (інші версії будуть більше ніж на одну мінорну версію відрізнятися від одного з компонентів kube-apiserver)
Підтримуваний порядок оновлення компонентів
Підтримувана версійна розбіжність між компонентами має наслідки для порядку, в якому компоненти повинні оновлюватися. Цей розділ описує порядок, у якому компоненти повинні оновлюватися для переходу поточного кластера з версії 1.31 до версії 1.32.
За бажанням, при підготовці до оновлення, проєкт Kubernetes рекомендує зробити наступне для отримання максимальної кількості виправлень та усунення помилок під час оновлення:
Переконайтеся, що компоненти знаходяться на найновішій патч-версії вашої поточної мінорної версії.
Оновіть компоненти до найновішої патч-версії цільової мінорної версії.
Наприклад, якщо ви використовуєте версію 1.31, переконайтеся, що ви використовуєте найновішу патч-версію. Потім оновіть до найновішої патч-версії 1.32.
kube-apiserver
Передумови:
У кластері, що складається з одного екземпляру, наявний екземпляр kube-apiserver має версію 1.31
У HA кластері всі екземпляри kube-apiserver мають версії 1.31 або 1.32 (це забезпечує максимальну різницю в 1 мінорну версію між найстарішим та найновішим екземпляром kube-apiserver)
Екземпляри kube-controller-manager, kube-scheduler та cloud-controller-manager, які взаємодіють з цим сервером, мають версію 1.31 (це забезпечує, що вони не новіші за поточну версію API сервера і знаходяться в межах 1 мінорної версії від нової версії API сервера)
Екземпляри kubelet на всіх вузлах мають версії 1.31 або 1.30 (це забезпечує, що вони не новіші за поточну версію API сервера і знаходяться в межах 2 мінорних версій від нової версії API сервера)
Зареєстровані вебхуки допуску здатні обробляти дані, які новий екземпляр kube-apiserver буде їм надсилати:
Обʼєкти ValidatingWebhookConfiguration та MutatingWebhookConfiguration оновлені для включення будь-яких нових версій REST ресурсів, доданих у 1.32 (або використовують опцію matchPolicy: Equivalent, доступну у версії v1.15+)
Вебхуки здатні обробляти будь-які нові версії REST ресурсів, які будуть їм надсилатися, і будь-які нові поля, додані до поточних версій у 1.32
Оновіть kube-apiserver до 1.32
Примітка:
Політики проєкту щодо застарівання API та
рекомендацій щодо змін API вимагають, щоб kube-apiserver не пропускав мінорні версії під час оновлення, навіть у кластерах, що складаються з одного екземпляру.
kube-controller-manager, kube-scheduler та cloud-controller-manager
Передумови:
Екземпляри kube-apiserver, з якими ці компоненти взаємодіють, мають версію 1.32 (у HA кластерах, в яких ці компоненти керування можуть взаємодіяти з будь-яким екземпляром kube-apiserver у кластері, всі екземпляри kube-apiserver повинні бути оновлені перед оновленням цих компонентів)
Оновіть kube-controller-manager, kube-scheduler та cloud-controller-manager до 1.32. Немає встановленого порядку оновлення між kube-controller-manager, kube-scheduler та cloud-controller-manager. Ви можете оновити ці компоненти в будь-якому порядку або навіть одночасно.
kubelet
Передумови:
Екземпляри kube-apiserver, з якими kubelet взаємодіє, мають версію 1.32
За бажанням, оновіть екземпляри kubelet до 1.32 (або їх можна залишити на версіях 1.31, 1.30, або 1.29)
Примітка:
Перед виконанням мінорного оновлення kubelet, виселіть Podʼи з цього вузла. Оновлення kubelet на місці до іншої мінорної версії не підтримується.
Попередження:
Запуск кластера з екземплярами kubelet, які постійно знаходяться на три мінорні версії позаду kube-apiserver, означає, що вони повинні бути оновлені перед оновленням контрольної площини.
kube-proxy
Передумови:
Екземпляри kube-apiserver, з якими kube-proxy взаємодіє, мають версію 1.32
За бажанням, оновіть екземпляри kube-proxy до 1.32 (або їх можна залишити на версіях 1.31, 1.30, або 1.29)
Попередження:
Запуск кластера з екземплярами kube-proxy, які постійно знаходяться на три мінорні версії позаду kube-apiserver, означає, що вони повинні бути оновлені перед оновленням панелі управління.