Проєкт Kubernetes підтримує гілки випусків для трьох останніх мінорних випусків (1.35, 1.34, 1.33). Kubernetes 1.19 та новіші отримують приблизно 1 рік патчі підтримки. Kubernetes 1.18 та старіші отримували патчі приблизно впродовж 9 місяців.
Версії Kubernetes зазначаються у вигляді x.y.z, де
Докладніше про політику розбіжностей між версіями у документі — Політика версійної розбіжності.
Ознайомтесь з графіком виходу майбутнього випуску 1.36 Kubernetes!
Зверніться до ресурсів команди випуску Kubernetes для ключової інформації про ролі та процес випуску.
Kubernetes надає бінарні файли для кожного компонента, а також стандартний набір клієнтських застосунків для початкового завантаження або взаємодії з кластером. Компоненти, такі як API-сервер, здатні працювати всередині контейнерних образів в кластері. Ці компоненти також постачаються в контейнерних образах як частина офіційного процесу випуску. Всі бінарні файли, а також контейнерні образи доступні для різних операційних систем та апаратних архітектур.
Інструмент командного рядка Kubernetes, kubectl, дозволяє виконувати команди в кластерах Kubernetes.
Ви можете використовувати kubectl для розгортання застосунків, інспектування та керування ресурсами кластера, а також перегляду логів. Для отримання додаткової інформації, включаючи повний список операцій kubectl, дивіться довідкову документацію kubectl.
kubectl можна встановити на різних платформах Linux, macOS і Windows. Знайдіть вашу операційну систему нижче.
Всі контейнерні образи Kubernetes розміщені в реєстрі контейнерних образів registry.k8s.io.
| Контейнерний образ | Підтримувані архітектури |
|---|---|
| registry.k8s.io/kube-apiserver:v1.35.0 | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/kube-controller-manager:v1.35.0 | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/kube-proxy:v1.35.0 | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/kube-scheduler:v1.35.0 | amd64, arm, arm64, ppc64le, s390x |
| registry.k8s.io/conformance:v1.35.0 | amd64, arm, arm64, ppc64le, s390x |
Всі контейнерні образи доступні для кількох архітектур, тоді як середовище виконання контейнерів має вибрати правильну архітектуру на основі базової платформи. Також можна витягнути образ для конкретної архітектури, додавши суфікс до імені контейнерного образу, наприклад registry.k8s.io/kube-apiserver-arm64:v1.35.0.
Kubernetes v1.26 [beta]
Для Kubernetes v1.35, контейнерні образи підписуються за допомогою sigstore підписів:
Проєкт Kubernetes публікує список підписаних контейнерних образів Kubernetes у форматі SPDX 2.3. Ви можете отримати цей список за допомогою:
curl -Ls "https://sbom.k8s.io/$(curl -Ls https://dl.k8s.io/release/stable.txt)/release" | grep "SPDXID: SPDXRef-Package-registry.k8s.io" | grep -v sha256 | cut -d- -f3- | sed 's/-/\//' | sed 's/-v1/:v1/'
Щоб вручну перевірити підписані контейнерні образи основних компонентів Kubernetes, зверніться до документа Перевірка підписаних контейнерних образів.
Якщо ви витягуєте образ контейнера для певної архітектури, то цей образ для однієї архітектури підписаний так само як і мультиархітектурні списки маніфестів.
Ви можете знайти посилання на завантаження компонентів Kubernetes (та їх контрольні суми) у файлах CHANGELOG. Або ж, скористайтесь downloadkubernetes.com для вибору за версією та архітектурою.
Розклад та контактна інформація команди патч-випусків Kubernetes.
Для загальної інформації про цикл випусків Kubernetes, дивіться опис процесу випуску.
Типова періодичність патч-випусків — щомісяця. Зазвичай вона трохи швидша (1-2 тижні) для перших патч-випусків після 1.X мінорного випуску. Критичні виправлення можуть призвести до негайного випуску поза звичайною періодичністю. Ми також намагаємося не робити випуски під час основних святкових періодів.
Дивіться сторінку Менеджери Випусків для отримання повних контактних даних команди патч-випусків.
Дайте нам хоча б один робочий день на відповідь — ми можемо бути в іншому часовому поясі!
Між випусками команда переглядає вхідні запити на cherry pick щотижня. Команда буде звʼязуватися з вами через GitHub PR, канали SIG у Slack, прямі повідомлення у Slack та email якщо є питання щодо PR.
Будь ласка, дотримуйтесь процесу cherry pick.
Cherry picks повинні бути готові до злиття у GitHub з правильними мітками (наприклад, approved, lgtm, release-note) та успішними CI тестами до граничного терміну для cherry pick. Зазвичай це за два дні до цільового випуску, але може бути й більше. Раніша готовність PR краще, оскільки нам потрібен час для отримання сигналу CI після злиття ваших cherry picks перед фактичним випуском.
Cherry pick PR, які не відповідають критеріям злиття, будуть перенесені та додані для наступного патч-випуску.
Відповідно до річної підтримки KEP, спільнота Kubernetes підтримуватиме активні серії патч-випусків протягом приблизно чотирнадцяти (14) місяців.
Перші дванадцять місяців цього терміну вважатимуться стандартним періодом.
Наприкінці дванадцятого місяця станеться наступне:
Протягом двомісячного періоду обслуговування Менеджери Випусків можуть робити додаткові випуски обслуговування для розвʼязання наступних проблем:
Наприкінці двомісячного періоду обслуговування серія патч-випусків вважатиметься завершеною (EOL) і cherry picks до відповідної гілки будуть закриті незабаром після цього.
Зверніть увагу, що 28-е число місяця було обрано як цільові дати для режиму обслуговування та EOL для зручності (кожен місяць має це число).
Часові рамки можуть змінюватися залежно від важливості виправлень, але для полегшення планування ми орієнтуватимемося на наступні щомісячні точки випуску. Незаплановані, критичні випуски можуть також відбуватися у проміжках між ними.
| Щомісячний випуск виправлень | Строк Cherry Pick | Заплановано |
|---|---|---|
| квітня 2026 | ||
| травня 2026 | ||
| червня 2026 |
Наступний патч 1.35.4.
1.35 переходить в режим технічного обслуговування , кінець життєвого циклу — .
| Патч | Строк Cherry Pick | Заплановано | Примітка |
|---|---|---|---|
| 1.35.3 | |||
| 1.35.2 | Out of band patch release to pick up a new version of Go to address several Go CVEs. No other changes. | ||
| 1.35.1 | January 2026 patches consolidated with February |
Наступний патч 1.34.7.
1.34 переходить в режим технічного обслуговування , кінець життєвого циклу — .
| Патч | Строк Cherry Pick | Заплановано | Примітка |
|---|---|---|---|
| 1.34.6 | |||
| 1.34.5 | Out of band patch release to pick up a new version of Go to address several Go CVEs. No other changes. | ||
| 1.34.4 | January 2026 patches consolidated with February | ||
| 1.34.3 | |||
| 1.34.2 | October 2025 patches consolidated with November | ||
| 1.34.1 | |||
| 1.34.0 | - |
Наступний патч 1.33.11.
1.33 переходить в режим технічного обслуговування , кінець життєвого циклу — .
| Патч | Строк Cherry Pick | Заплановано | Примітка |
|---|---|---|---|
| 1.33.10 | |||
| 1.33.9 | Out of band patch release to pick up a new version of Go to address several Go CVEs. No other changes. | ||
| 1.33.8 | January 2026 patches consolidated with February | ||
| 1.33.7 | |||
| 1.33.6 | October 2025 patches consolidated with November | ||
| 1.33.5 | |||
| 1.33.4 | |||
| 1.33.3 | |||
| 1.33.2 | |||
| 1.33.1 |
Ці випуски більше не підтримуються.
| Мінорна версія | Остаточний патч-випуск | Завершення життєвого циклу | Примітка |
|---|---|---|---|
| 1.32 | 1.32.13 | ||
| 1.31 | 1.31.14 | ||
| 1.30 | 1.30.14 | ||
| 1.29 | 1.29.14 | ||
| 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 |
"Менеджери Випусків" — це загальний термін, що охоплює групу учасників Kubernetes, відповідальних за підтримку гілок випусків та створення випусків, використовуючи інструменти, надані SIG Release.
Обовʼязки кожної ролі описані нижче.
| Список Розсилки | Slack | Видимість | Використання | Членство |
|---|---|---|---|---|
| release-managers@kubernetes.io | #release-management (канал) / @release-managers (група користувачів) | Публічний | Публічні обговорення для Менеджерів Випусків | Усі Менеджери Випусків (включаючи Асистентів та Голов SIG) |
| release-managers-private@kubernetes.io | N/A | Приватний | Приватні обговорення для привілейованих Менеджерів Випусків | Менеджери Випусків, лідерство SIG Release |
| security-release-team@kubernetes.io | #security-release-team (канал) / @security-rel-team (група користувачів) | Приватний | Координація безпеки випусків з Комітетом з Відповіді на Безпеку | security-discuss-private@kubernetes.io, release-managers-private@kubernetes.io |
Деяка інформація про випуски підлягає закритості, і ми визначили політику щодо того, як ці обмеження встановлюються. Будь ласка, зверніться до Політики закритості за для безпеки для отримання додаткової інформації.
Примітка: Довідники для Команди Патч-Випусків та Менеджерів Гілок будуть уніфіковані пізніше.
Примітка: У документації можуть згадуватися Команда Патч-Випусків та роль Менеджера Гілок. Ці дві ролі були обʼєднані у роль Менеджерів Випусків.
Мінімальні вимоги до Менеджерів Випусків та Асистентів Менеджерів Випусків:
git та відповідними командами командного рядка git.Менеджери Випусків відповідають за:
x.y.z, де z > 0)x.y.z, де z = 0)Ця команда іноді працює у тісному контакті з Security Response Committee і тому повинна дотримуватися рекомендацій, викладених у Процесі Безпеки Випуску.
Контроль доступу GitHub: @kubernetes/release-managers
Посилання на GitHub: @kubernetes/release-engineering
Щоб стати Менеджером Випусків, необхідно спочатку бути Асистентом Менеджера Випусків. Асистенти переходять до ролі Менеджера Випусків, активно працюючи над випусками протягом кількох циклів та:
Асистенти Менеджерів Випусків є стажерами Менеджерів Випусків, раніше відомими як тіні Менеджерів Випусків. Вони відповідають за:
Посилання на GitHub: @kubernetes/release-engineering
Учасники можуть стати Асистентами, демонструючи наступне:
Голови та Технічні Лідери SIG Release відповідають за:
Вони згадуються тут, оскільки є власниками різних каналів спілкування та груп дозволів (команди GitHub, доступ GCP) для кожної ролі. Таким чином, вони є високопривілейованими членами спільноти та мають доступ до деяких приватних комунікацій, які іноді можуть стосуватися розголошення безпеки Kubernetes.
Команда GitHub: @kubernetes/sig-release-leads
Колишніх Менеджерів Гілок можна знайти в теці releases репозиторію kubernetes/sig-release у файлах release-x.y/release_team.md.
Приклад: Команда Випуску 1.15
Нотатки про випуски можна знайти, переглянувши Changelog, який відповідає вашій версії Kubernetes. Перегляньте changelog для 1.35 на GitHub.
Або, нотатки про випуски можна шукати та фільтрувати онлайн на: relnotes.k8s.io. Перегляньте відфільтровані нотатки про випуск для 1.35 на relnotes.k8s.io.
Цей документ описує максимально підтримувану версійну розбіжність між різними компонентами Kubernetes. Конкретні інструменти розгортання кластерів можуть накладати додаткові обмеження на версійну розбіжність.
Версії Kubernetes позначаються як x.y.z, де x — основна версія, y — мінорна версія, а z — патч-версія, згідно з термінологією Семантичного Версіонування. Для отримання додаткової інформації дивіться Kubernetes Release Versioning.
Проєкт Kubernetes підтримує гілки випусків для останніх трьох мінорних випусків (1.35, 1.34, 1.33). Kubernetes 1.19 та новіші версії отримують приблизно 1 рік патч-підтримки. Kubernetes 1.18 та старіші отримували приблизно 9 місяців патч-підтримки.
Відповідні виправлення, включаючи виправлення безпеки, можуть бути перенесені на ці три гілки випусків залежно від серйозності та здійсненності. Патч-випуски вирізаються з цих гілок на регулярній основі, а також додаткові термінові випуски, коли це необхідно.
Група Менеджерів Релізів володіє цим рішенням.
Для отримання додаткової інформації дивіться сторінку Патч-випуски Kubernetes.
У кластері з високою доступністю (HA), найновіші та найстаріші екземпляри kube-apiserver повинні бути в межах однієї мінорної версії.
Приклад:
kube-apiserver має версію 1.35kube-apiserver підтримуються на версіях 1.35 та 1.34kubelet не повинен бути новішим за kube-apiserver.kubelet може бути до трьох мінорних версій старішим за kube-apiserver (kubelet < 1.25 може бути не більше ніж на дві мінорні версії старішим за kube-apiserver).Приклад:
kube-apiserver має версію 1.35kubelet підтримується на версіях 1.35, 1.34, 1.33 та 1.32kube-apiserver у HA кластері, це звужує допустимі версії kubelet.Приклад:
kube-apiserver мають версії 1.35 та 1.34kubelet підтримується на версіях 1.34, 1.33, та 1.32 (1.35 не підтримується, оскільки це було б новішим за екземпляр kube-apiserver з версією 1.34)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.35kube-proxy підтримується на версіях 1.35, 1.34, 1.33 та 1.32kube-apiserver у HA кластері, це звужує допустимі версії kube-proxy.Приклад:
kube-apiserver мають версії 1.35 та 1.34kube-proxy підтримується на версіях 1.34, 1.33, та 1.32 (1.35 не підтримується, оскільки це було б новішим за екземпляр kube-apiserver з версією 1.34)kube-controller-manager, kube-scheduler та cloud-controller-manager не повинні бути новішими за екземпляри kube-apiserver, з якими вони взаємодіють. Вони повинні відповідати мінорній версії kube-apiserver, але можуть бути до однієї мінорної версії старішими (для дозволу на живі оновлення).
Приклад:
kube-apiserver має версію 1.35kube-controller-manager, kube-scheduler та cloud-controller-manager підтримуються на версіях 1.35 та 1.34kube-apiserver у HA кластері, і ці компоненти можуть взаємодіяти з будь-яким екземпляром kube-apiserver у кластері (наприклад, через балансувальник навантаження), це звужує допустимі версії цих компонентів.Приклад:
kube-apiserver мають версії 1.35 та 1.34kube-controller-manager, kube-scheduler та cloud-controller-manager взаємодіють з балансувальником навантаження, який може направляти запити до будь-якого екземпляра kube-apiserverkube-controller-manager, kube-scheduler та cloud-controller-manager підтримуються на
версіях 1.34 (1.35 не підтримується, оскільки це було б новішим за екземпляр kube-apiserver з версією 1.34)kubectl підтримується в межах однієї мінорної версії (старішої або новішої) від kube-apiserver.
Приклад:
kube-apiserver має версію 1.35kubectl підтримується на версіях 1.36, 1.35, та 1.34kube-apiserver у HA кластері, це звужує підтримувані версії kubectl.Приклад:
kube-apiserver мають версії 1.35 та 1.34kubectl підтримується на версіях 1.35 та 1.34 (інші версії будуть більше ніж на одну мінорну версію відрізнятися від одного з компонентів kube-apiserver)Підтримувана версійна розбіжність між компонентами має наслідки для порядку, в якому компоненти повинні оновлюватися. Цей розділ описує порядок, у якому компоненти повинні оновлюватися для переходу поточного кластера з версії 1.34 до версії 1.35.
За бажанням, при підготовці до оновлення, проєкт Kubernetes рекомендує зробити наступне для отримання максимальної кількості виправлень та усунення помилок під час оновлення:
Наприклад, якщо ви використовуєте версію 1.34, переконайтеся, що ви використовуєте найновішу патч-версію. Потім оновіть до найновішої патч-версії 1.35.
Передумови:
kube-apiserver має версію 1.34kube-apiserver мають версії 1.34 або 1.35 (це забезпечує максимальну різницю в 1 мінорну версію між найстарішим та найновішим екземпляром kube-apiserver)kube-controller-manager, kube-scheduler та cloud-controller-manager, які взаємодіють з цим сервером, мають версію 1.34 (це забезпечує, що вони не новіші за поточну версію API сервера і знаходяться в межах 1 мінорної версії від нової версії API сервера)kubelet на всіх вузлах мають версії 1.34 або 1.33 (це забезпечує, що вони не новіші за поточну версію API сервера і знаходяться в межах 2 мінорних версій від нової версії API сервера)kube-apiserver буде їм надсилати:
ValidatingWebhookConfiguration та MutatingWebhookConfiguration оновлені для включення будь-яких нових версій REST ресурсів, доданих у 1.35 (або використовують опцію matchPolicy: Equivalent, доступну у версії v1.15+)Оновіть kube-apiserver до 1.35
kube-apiserver не пропускав мінорні версії під час оновлення, навіть у кластерах, що складаються з одного екземпляру.Передумови:
kube-apiserver, з якими ці компоненти взаємодіють, мають версію 1.35 (у HA кластерах, в яких ці компоненти керування можуть взаємодіяти з будь-яким екземпляром kube-apiserver у кластері, всі екземпляри kube-apiserver повинні бути оновлені перед оновленням цих компонентів)Оновіть kube-controller-manager, kube-scheduler та cloud-controller-manager до 1.35. Немає встановленого порядку оновлення між kube-controller-manager, kube-scheduler та cloud-controller-manager. Ви можете оновити ці компоненти в будь-якому порядку або навіть одночасно.
Передумови:
kube-apiserver, з якими kubelet взаємодіє, мають версію 1.35За бажанням, оновіть екземпляри kubelet до 1.35 (або їх можна залишити на версіях 1.34, 1.33, або 1.32)
kubelet, виселіть Podʼи з цього вузла. Оновлення kubelet на місці до іншої мінорної версії не підтримується.kubelet, які постійно знаходяться на три мінорні версії позаду kube-apiserver, означає, що вони повинні бути оновлені перед оновленням контрольної площини.Передумови:
kube-apiserver, з якими kube-proxy взаємодіє, мають версію 1.35За бажанням, оновіть екземпляри kube-proxy до 1.35 (або їх можна залишити на версіях 1.34, 1.33, або 1.32)
kube-proxy, які постійно знаходяться на три мінорні версії позаду kube-apiserver, означає, що вони повинні бути оновлені перед оновленням панелі управління.