Випуски

• 1: Завантаження Kubernetes
• 2: Патч-випуски
• 3: Менеджери випусків
• 4: Нотатки
• 5: Політика версійної розбіжності
• 6: Цикл випуску Kubernetes

1 - Завантаження Kubernetes

Kubernetes надає бінарні файли для кожного компонента, а також стандартний набір клієнтських застосунків для початкового завантаження або взаємодії з кластером. Компоненти, такі як API-сервер, здатні працювати всередині контейнерних образів в кластері. Ці компоненти також постачаються в контейнерних образах як частина офіційного процесу випуску. Всі бінарні файли, а також контейнерні образи доступні для різних операційних систем та архітектур апаратного забезпечення.

kubectl

Командний рядок Kubernetes, kubectl, дозволяє виконувати команди в кластерах Kubernetes.

Ви можете використовувати kubectl для розгортання застосунків, інспектування та керування ресурсами кластера, а також перегляду логів. Для отримання додаткової інформації, включаючи повний список операцій kubectl, дивіться довідкову документацію kubectl.

kubectl можна встановити на різних платформах Linux, macOS і Windows. Знайдіть вашу операційну систему нижче.

• Встановити kubectl на Linux
• Встановити kubectl на macOS
• Встановити kubectl на Windows

Контейнерні образи

Всі контейнерні образи Kubernetes розміщені в реєстрі контейнерних образів registry.k8s.io.

Архітектури контейнерних образів

Всі контейнерні образи доступні для кількох архітектур, тоді як середовище виконання контейнерів має вибрати правильну архітектуру на основі базової платформи. Також можна витягнути образ для конкретної архітектури, додавши суфікс до імені контейнерного образу, наприклад registry.k8s.io/kube-apiserver-arm64:v1.31.0.

Підписи контейнерних образів

Для Kubernetes v1.31, контейнерні образи підписуються за допомогою 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, зверніться до документа Перевірка підписаних контейнерних образів.

Якщо ви витягуєте образ контейнера для певної архітектури, то цей образ для однієї архітектури підписаний так само як і мультиархітектурні списки маніфестів.

Бінарні файли

2 - Патч-випуски

Розклад та контактна інформація для патч-випусків Kubernetes.

Для загальної інформації про цикл випусків Kubernetes, дивіться опис процесу випуску.

Періодичність

Типова періодичність патч-випусків — щомісяця. Зазвичай вона трохи швидша (1-2 тижні) для перших патч-випусків після 1.X мінорного випуску. Критичні виправлення можуть призвести до негайного випуску поза звичайною періодичністю. Ми також намагаємося не робити випуски під час основних святкових періодів.

Контакт

Дивіться сторінку Менеджери Випусків для отримання повних контактних даних команди патч-випусків.

Дайте нам хоча б один робочий день на відповідь — ми можемо бути в іншому часовому поясі!

Між випусками команда переглядає вхідні запити на cherry pick щотижня. Команда буде звʼязуватися з вами через GitHub PR, канали SIG у Slack, прямі повідомлення у Slack та email якщо є питання щодо PR.

Cherry picks

Будь ласка, дотримуйтесь процесу cherry pick.

Cherry picks повинні бути готові до злиття у GitHub з правильними мітками (наприклад, approved, lgtm, release-note) та успішними CI тестами до граничного терміну для cherry pick. Зазвичай це за два дні до цільового випуску, але може бути й більше. Раніша готовність PR краще, оскільки нам потрібен час для отримання сигналу CI після злиття ваших cherry picks перед фактичним випуском.

Cherry pick PR, які не відповідають критеріям злиття, будуть перенесені та додані для наступного патч-випуску.

Період підтримки

Відповідно до річної підтримки KEP, спільнота Kubernetes підтримуватиме активні серії патч-випусків протягом приблизно чотирнадцяти (14) місяців.

Перші дванадцять місяців цього терміну вважатимуться стандартним періодом.

Наприкінці дванадцятого місяця станеться наступне:

• Менеджери Випусків зроблять випуск
• Серія патч-випусків перейде в режим обслуговування

Протягом двомісячного періоду обслуговування Менеджери Випусків можуть робити додаткові випуски обслуговування для розвʼязання наступних проблем:

• Вразливості, які отримали CVE ID (за порадою Security Response Committee)
• проблеми із залежностями (включаючи оновлення базових образів)
• критичні проблеми основних компонентів

Наприкінці двомісячного періоду обслуговування серія патч-випусків вважатиметься завершеною (EOL) і cherry picks до відповідної гілки будуть закриті незабаром після цього.

Зверніть увагу, що 28-е число місяця було обрано як цільові дати для режиму обслуговування та EOL для зручності (кожен місяць має це число).

Майбутні щомісячні випуски

Часові рамки можуть змінюватися залежно від важливості виправлень, але для полегшення планування ми орієнтуватимемося на наступні щомісячні точки випуску. Незаплановані, критичні випуски можуть також відбуватися у проміжках між ними.

Детальна історія випусків для активних гілок

1.31

Наступний патч 1.31.3.

Kubernetes 1.31 переходить у режим підтримки з 28 серп. 2025 р.; дата закінчення життєвого циклу Kubernetes 1.31 — 28 жовт. 2025 р..

1.30

Наступний патч 1.30.7.

Kubernetes 1.30 переходить у режим підтримки з 28 квіт. 2025 р.; дата закінчення життєвого циклу Kubernetes 1.30 — 28 черв. 2025 р..

1.29

Наступний патч 1.29.11.

Kubernetes 1.29 переходить у режим підтримки з 28 груд. 2024 р.; дата закінчення життєвого циклу Kubernetes 1.29 — 28 лют. 2025 р..

Історія неактивних гілок

Ці випуски більше не підтримуються.

3 - Менеджери випусків

"Менеджери Випусків" — це загальний термін, що охоплює групу учасників Kubernetes, відповідальних за підтримку гілок випусків та створення випусків, використовуючи інструменти, надані SIG Release.

Обовʼязки кожної ролі описані нижче.

• Контакти
  • Політика закритості за для безпеки
• Довідники
• Менеджери випусків
  • Як стати менеджером випусків
• Асистенти менеджерів випусків
  • Як стати асистентом менеджера випусків
• Лідери SIG Release
  • Голови
  • Технічні лідери

Контакти

Політика закритості за для безпеки

Деяка інформація про випуски підлягає закритості, і ми визначили політику щодо того, як ці обмеження встановлюються. Будь ласка, зверніться до Політики закритості за для безпеки для отримання додаткової інформації.

Довідники

Примітка: Довідники для Команди Патч-Випусків та Менеджерів Гілок будуть уніфіковані пізніше.

• Команда Патч-Випусків
• Менеджери Гілок

Менеджери випусків

Примітка: У документації можуть згадуватися Команда Патч-Випусків та роль Менеджера Гілок. Ці дві ролі були обʼєднані у роль Менеджерів Випусків.

Мінімальні вимоги до Менеджерів Випусків та Асистентів Менеджерів Випусків:

• Знайомство з основними командами Unix та здатність налагоджувати shell скрипти.
• Знайомство з розгалуженими робочими процесами з кодом в git та відповідними викликами командного рядка git.
• Загальні знання про Google Cloud (Cloud Build та Cloud Storage).
• Готовність звертатися за допомогою та чітко спілкуватися.
• Членство в спільноті Kubernetes membership

Менеджери Випусків відповідають за:

• Координацію та проведення випусків Kubernetes:
  • Патч-випуски (x.y.z, де z > 0)
  • Мінорні випуски (x.y.z, де z = 0)
  • Попередні випуски (alpha, beta та випуск-кандидати)
  • Роботу з Командою Випуску протягом кожного циклу випуску
  • Встановлення графіку та періодичності патч-випусків
• Підтримку гілок випусків:
  • Перегляд cherry picks
  • Забезпечення справності гілки випуску та недопущення непередбачених патчів
• Наставництво для групи Асистентів Менеджерів Випусків
• Активну розробку функцій та підтримку коду в k/release
• Підтримку Асистентів Менеджерів Випусків та учасників через активну участь у програмі наставництва
  • Щомісячні перевірки з Асистентами та делегування завдань, надання можливості їм проводити випуски та наставництво
  • Бути доступним для підтримки Асистентів у інтеграції нових учасників, наприклад, відповідаючи на питання та пропонуючи відповідні завдання для них

Ця команда іноді працює у тісному контакті з Security Response Committee і тому повинна дотримуватися рекомендацій, викладених у Процесі Безпеки Випуску.

Контроль доступу GitHub: @kubernetes/release-managers

Згадки GitHub: @kubernetes/release-engineering

• Адольфо Гарсія Вейтіа [Adolfo García Veytia] (@puerco)
• Сісі Хуанг [Cici Huang] (@cici37)
• Карлос Панато [Carlos Panato] (@cpanato)
• Джеремі Рікард [Jeremy Rickard] (@jeremyrickard)
• Марко Мудриніч [Marko Mudrinić] (@xmudrii)
• Набарун Пал [Nabarun Pal] (@palnabarun)
• Саша Грунерт [Sascha Grunert] (@saschagrunert)
• Стівен Августус [Stephen Augustus] (@justaugustus)
• Вероніка Лопес [Verónica López] (@verolop)

Як стати менеджером випусків

Щоб стати Менеджером Випусків, необхідно спочатку бути Асистентом Менеджера Випусків. Асистенти переходять до ролі Менеджера Випусків, активно працюючи над випусками протягом кількох циклів та:

• демонструючи готовність до лідерства
• працюючи разом з Менеджерами Випусків над патчами, щоб у результаті провести випуск самостійно
  • оскільки випуски мають обмежувальну функцію, ми також розглядаємо значні внески у просування образів та інші основні завдання Інженерії Випусків
• ставлячи питання про роботу Асистентів, пропонуючи покращення, збираючи відгуки та впроваджуючи зміни
• будучи надійними та відповідальними
• займаючись складними завданнями, які вимагають доступу та привілеїв рівня Менеджера Випусків для завершення

Асистенти менеджерів випусків

Асистенти Менеджерів Випусків є стажерами Менеджерів Випусків, раніше відомими як тіні Менеджерів Випусків. Вони відповідають за:

• Роботу над патч-випусками, перегляд cherry picks
• Внесок у k/release: оновлення залежностей та ознайомлення з кодовою базою
• Внесок у документацію: підтримку довідників, забезпечення документування процесів випуску
• За допомогою Менеджера Випусків: роботу з Командою Випуску протягом циклу випуску та проведення випусків Kubernetes
• Пошук можливостей для допомоги у пріоритизації та комунікації
  • Надсилання попередніх оголошень та оновлень про патч-випуски
  • Оновлення календаря, допомога з датами випуску та віхами з графіку циклу випуску
• Через програму Buddy, інтеграція нових учасників та співпраця з ними над завданнями

Згадки GitHub: @kubernetes/release-engineering

• Арно Меукам [Arnaud Meukam] (@ameukam)
• Джим Анжел [Jim Angel] (@jimangel)
• Джозеф Сандовал [Joseph Sandoval] (@jrsapi)
• Ксандер Гжижинскі [Xander Grzywinski] (@salaxander)

Як стати асистентом менеджера випусків

Учасники можуть стати Асистентами, демонструючи наступне:

• послідовну участь, включаючи 6-12 місяців активної роботи, повʼязаної з інженерною роботою, повʼязаною з випусками
• досвід виконання ролі технічного лідера у Команді Випуску протягом циклу випуску
  • цей досвід надає міцну базу для розуміння роботи SIG Release загалом — включаючи наші очікування щодо технічних навичок, комунікацій/відповідальності та надійності
• роботу над завданнями k/release, що покращують взаємодію з Testgrid, очищення бібліотек тощо
  • ці зусилля вимагають взаємодії та співпраці з Менеджерами Випусків та Асистентами

Лідери SIG Release

Голови та Технічні Лідери SIG Release відповідають за:

• Управління SIG Release
• Проведення сесій обміну знаннями для Менеджерів Випусків та Асистентів
• Наставництво з питань лідерства та пріоритизації

Вони згадуються тут, оскільки є власниками різних каналів спілкування та груп дозволів (команди GitHub, доступ GCP) для кожної ролі. Таким чином, вони є високопривілейованими членами спільноти та мають доступ до деяких приватних комунікацій, які іноді можуть стосуватися розголошення безпеки Kubernetes.

Команда GitHub: @kubernetes/sig-release-leads

Голови

• Джеремі Рікард [Jeremy Rickard] (@jeremyrickard)
• Саша Грунерт [Sascha Grunert] (@saschagrunert)
• Стівен Августус [Stephen Augustus] (@justaugustus)

Технічні Лідери

• Адольфо Гарсія Вейтіа [Adolfo García Veytia] (@puerco)
• Карлос Панато [Carlos Panato] (@cpanato)
• Вероніка Лопес [Verónica López] (@verolop)

Колишніх Менеджерів Гілок можна знайти в теці releases репозиторію kubernetes/sig-release у файлах release-x.y/release_team.md.

Приклад: Команда Випуску 1.15

4 - Нотатки

Нотатки про випуски можна знайти, переглянувши Changelog, який відповідає вашій версії Kubernetes. Перегляньте changelog для 1.31 на GitHub.

Або, нотатки про випуски можна шукати та фільтрувати онлайн на: relnotes.k8s.io. Перегляньте відфільтровані нотатки про випуски для 1.31 на relnotes.k8s.io.

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

Цей документ описує максимально підтримувану версійну розбіжність між різними компонентами 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.31
• kubelet підтримується на версіях 1.31, 1.30, 1.29 та 1.28

Приклад:

• екземпляри 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.31
• kube-proxy підтримується на версіях 1.31, 1.30, 1.29 та 1.28

Приклад:

• екземпляри 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.31
• kube-controller-manager, kube-scheduler та cloud-controller-manager підтримуються на версіях 1.31 та 1.30

Приклад:

• екземпляри 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.31
• kubectl підтримується на версіях 1.32, 1.31, та 1.30

Приклад:

• екземпляри 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

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)

kube-proxy

Передумови:

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

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

6 - Цикл випуску Kubernetes

Орієнтація на поліпшення, Тікети та PR для віх випуску

Цей документ орієнтований на розробників та учасників Kubernetes, які повинні створювати поліпшення, тікети або pull request (PR), що спрямовані на конкретну віху випуску.

• TL;DR
  • Звичайна розробка (Тижні 1-11)
  • Заморожування коду (Тижні 12-14)
  • Після випуску (Тижні 14+)
• Визначення
• Цикл випуску
• Видалення елементів з віхи
• Додавання елемента до віхи
  • Відповідальні за віхи
  • Додавання функціоналу
  • Додавання тікетів
  • Додавання PR
• Інші обовʼязкові мітки
  • Мітка власника SIG
  • Мітка пріоритету
  • Мітка виду проблеми/PR

Процес управління поліпшеннями, тікетами та pull request у випуску Kubernetes охоплює кілька зацікавлених сторін:

• власники поліпшень, проблем та pull request
• керівництво SIG
• Команда випуску

Інформація про робочі процеси та взаємодії описана нижче.

Як власник поліпшення, проблеми або PR, ви несете відповідальність за забезпечення виконання вимог до етапів випуску. Команди автоматизації та випуску будуть звʼязуватися з вами, якщо необхідні оновлення, але бездіяльність може призвести до видалення вашої роботи з віхи. Додаткові вимоги існують, якщо цільова віха — це попередній випуск (див. процес cherry pick для отримання додаткової інформації).

TL;DR

Якщо ви хочете, щоб ваш PR було прийнято, він повинен мати наступні обовʼязкові мітки та віхи, представлені тут командами Prow, необхідними для їх додавання:

Звичайна розробка (Тижні 1-11)

• /sig {назва}
• /kind {тип}
• /lgtm
• /approved

Заморожування коду (Тижні 12-14)

• /milestone {v1.y}
• /sig {назва}
• /kind {bug, failing-test}
• /lgtm
• /approved

Після випуску (Тижні 14+)

Повернення до вимог фази 'Звичайної розробки':

• /sig {назва}
• /kind {тип}
• /lgtm
• /approved

Злиття в гілку 1.y тепер відбувається через cherry pick, затверджені Менеджерами випуску.

Раніше була вимога, щоб pull request, націлені на етапи випуску, мали повʼязаний тікет в GitHub, але зараз це більше не потрібно. Функції або вдосконалення фактично є тікетами GitHub або KEPs, які призводять до подальших PR.

Процес позначення мітками повинен бути послідовним для всіх типів артефактів.

Визначення

• issue owners (власники тікетів): Автор, відповідальні та користувач, який перемістив тікет у віху випуску

• Release Team (Команда випуску): Кожен випуск Kubernetes має команду, яка виконує завдання управління проєктом, описані тут.

  Контактну інформацію для команди, повʼязаної з будь-яким даним випуском, можна знайти тут.

• Y days (Робочі дні): Стосується робочих днів

• enhancement (поліпшення): дивіться "Is My Thing an Enhancement?"

• Enhancements Freeze (Заморожування поліпшень): граничний термін, до якого KEP мають бути завершені, щоб поліпшення стали частиною поточного випуску

• Exception Request (Запит на виняток): Процес запиту продовження терміну для конкретного поліпшення

• Code Freeze (Заморожування коду): Період приблизно 4 тижні до фінальної дати випуску, протягом якого до релізного коду приймаються лише критичні виправлення помилок.

• Pruning (Очищення): Процес видалення поліпшення з віхи випуску, якщо воно не повністю реалізоване або вважається нестабільним.

• release milestone (віха випуску): семантичний рядок версії або віха GitHub, що стосується випуску MAJOR.MINOR версії vX.Y.

  Дивіться також версіювання випусків.

• гілка випуску (release branch): Гілка Git release-X.Y, створена для віхи vX.Y.

  Створюється на момент випуску vX.Y-rc.0 і підтримується після випуску приблизно протягом 12 місяців з патч-випусками vX.Y.Z.

  Примітка: випуски 1.19 і новіші отримують 1 рік підтримки патч-випусків, а випуски 1.18 і раніші отримували 9 місяців підтримки патч-випусків.

Цикл випуску

Випуски Kubernetes наразі відбуваються приблизно три рази на рік.

Процес випуску можна умовно розділити на три основні фази:

• Визначення покращень
• Реалізація
• Стабілізація

Але насправді це проєкт з відкритим кодом і гнучким підходом, де планування та впровадження нових функцій відбувається постійно. Враховуючи масштаб проєкту та розподілену по всьому світу базу розробників, критично важливо для швидкості проєкту не покладатися на фінальну фазу стабілізації, а натомість мати безперервне тестування інтеграції, що забезпечує стабільність проєкту, щоб окремі внески можна було відмітити як такі, що щось зламали.

Протягом року, коли триває визначення нових функцій, деякі з них стають ціллю для конкретного випуску. Замороження покращень починається приблизно через 4 тижні після початку циклу випуску. На цей момент всі заплановані роботи для даного випуску мають бути визначені у відповідних планових артефактах у співпраці з Лідером покращень Команди Випуску.

Після Замороження покращень важливо відстежувати віхи в PR та тікетах. Елементи в межах віхи використовуються як список для завершення випуску. В тікетах віхи мають бути правильно застосовані через сортування SIG, щоб Команда Випуску могла відстежувати проблеми та покращення (будь-який тікет, пов’язаний з покращенням, потребує віхи).

Існує певна автоматизація, яка допомагає автоматично призначати віхи PR.

Ця автоматизація наразі застосовується до наступних репозиторіїв:

• kubernetes/enhancements
• kubernetes/kubernetes
• kubernetes/release
• kubernetes/sig-release
• kubernetes/test-infra

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

Будь-які інші зусилля, які мають відстежуватись Командою Випуску, що не підпадають під цю автоматизацію, мають отримати віху.

Реалізація та виправлення проблем тривають протягом усього циклу, але завершуються періодом замороження коду.

Замороження коду починається на 12 тижні та триває приблизно 2 тижні. Лише критичні виправлення помилок приймаються в кодову базу випуску під час цього періоду.

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

Коли кодова база достатньо стабільна, гілка master знову відкривається для загальної розробки, і робота починається над наступним етапом випуску. Будь-які залишкові модифікації для поточного випуску вибираються з master назад у гілку випуску. Випуск будується з гілки release.

Кожен випуск є частиною ширшого життєвого циклу Kubernetes:

Видалення елементів з віхи

Перед тим як заглибитися у процес додавання елемента до віхи, будь ласка, зверніть увагу:

Члени Команди Випуску можуть видалити тікет з віхи, якщо вони або відповідальний SIG визначать, що проблема насправді не блокує випуск і навряд чи буде вирішена вчасно.

Члени Команди Випуску можуть видалити PR з віхи з будь-якої з наступних або подібних причин:

• PR потенційно дестабілізуючий і не потрібний для вирішення блокуючої проблеми
• PR є новою, пізньою функцією і не пройшов процес покращень або процес винятків
• Відповідальний SIG не бажає взяти на себе відповідальність за PR і вирішити будь-які подальші проблеми з ним
• PR неправильно позначений
• Робота над PR видимо припинилася, а дати впровадження невизначені або запізнілі

Хоча члени Команди Випуску допоможуть з позначенням мітками та спілкуванням SIG(ів), відповідальність за категоризацію PR лежить на авторі, а також на отриманні підтримки від відповідного SIG для гарантування того, що будь-який збій, викликаний PR, буде швидко вирішений.

Де потрібно додаткове втручання, спроба ескалації буде зроблена Командою Випуску через такі канали:

• Коментар на GitHub, що згадує команду SIG та членів SIG відповідно до типу проблеми
• Надсилання електронного листа у список розсилки SIG
  • ініціалізовано з групових електронних адрес зі списку спільноти SIG
  • за бажанням також безпосередньо звертаючись до керівництва SIG або інших членів SIG
• Повідомлення в Slack-каналі SIG
  • ініціалізовано зі slack-каналу та керівництва SIG зі списку спільноти SIG
  • за бажанням безпосередньо згадуючи керівництво SIG або інших через "@".

Додавання елемента до віхи

Відповідальні за віхи

Члени команди milestone-maintainers на GitHub відповідають за визначення етапу випуску для артефактів на GitHub.

Ця група керується SIG Release і має представників від різних керівників SIG.

Додавання функцій

Планування та визначення функцій сьогодні мають багато форм, але типовим прикладом може бути великий обсяг роботи, описаний у KEP, з відповідними завданнями на GitHub. Коли план досягнув стану, готового до реалізації, і робота вже триває, покращення або його частини стають цілями для найближчої віхи, створюючи завдання на GitHub і позначаючи їх командою Prow "/milestone".

Протягом перших ~4 тижнів циклу випуску Лідер покращень Команди Випуску буде взаємодіяти з SIG та власниками функцій через GitHub, Slack і зустрічі SIG, щоб зібрати всі необхідні планові артефакти.

Якщо у вас є покращення, яке ви хочете націлити на майбутню віху випуску, почніть розмову з керівництвом вашого SIG та з Лідером покращень цього випуску.

Додавання тікетів

Тікети позначаються як цільові для етапу через команду Prow "/milestone".

Лідер з сортування проблем Команди Випуску Bug Triage Lead та загальна спільнота відстежують нові завдання і сортують їх, як це описано в розділі посібника для учасників щодо сортування завдань.

Позначення завдань віхою надає спільноті краще розуміння того, коли проблема була виявлена і коли, на думку спільноти, вона має бути вирішена. Під час Замороження коду віха має бути встановлена для злиття PR.

Відкритий тікет більше не є обов’язковим для PR, але відкриті тікети та повʼязані PR повинні мати синхронізовані мітки. Наприклад, PR з високим пріоритетом проблеми може не бути злитим, якщо він позначений як нижчий пріоритет.

Додавання PR

PR позначаються як цільові для віхи через команду Prow "/milestone".

Це є обовʼязковою вимогою під час Замороження коду, як описано вище.

Інші обовʼязкові мітки

Ось список міток, їх використання та призначення.

Мітка власника SIG

Мітка власника SIG визначає SIG, до якої ми звертаємось, якщо проблема з віхою залишається без змін або потребує додаткової уваги. Якщо після ескалації немає оновлень, проблему може бути автоматично видалено з віхи.

Ці мітки додаються за допомогою команди Prow "/sig". Наприклад, щоб додати мітку, що SIG Storage відповідає, прокоментуйте /sig storage.

Мітка пріоритету

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

• priority/critical-urgent: Ніколи автоматично не видаляти з віхи випуску; постійно ескалювати до учасника та SIG через всі доступні канали.
  • вважається блокуючим випуск питанням
  • потребує щоденних оновлень від власників тікета під час Замороження коду
  • потребуватиме випуску патча, якщо його не виявили до завершення мінорного випуску
• priority/important-soon: Ескалювати до власників питання та власника SIG; видалити з віхи після кількох невдалих спроб ескалації.
  • не вважається блокуючим випуск питанням
  • не потребуватиме випуску патча
  • автоматично буде видалено з віхи випуску під час Замороження коду після 4-денної пільгового періоду
• priority/important-longterm: Ескалювати до власників питання; видалити з віхи після 1 спроби.
  • менш термінове / критичне, ніж priority/important-soon
  • видаляється з віхи більш агресивно, ніж priority/important-soon

Мітка типу тікета/PR

Тип тікета використовується для допомоги у визначенні типів змін, що включаються у випуск з часом. Це може дозволити Команді Випуску краще розуміти, які типи питань ми могли б пропустити з більш швидким темпом випуску.

Для випуску цільових завдань, включаючи pull request-и, повинна бути встановлена одна з наступних міток типу:

• kind/api-change: Додає, видаляє або змінює API
• kind/bug: Виправляє нововиявлений баг.
• kind/cleanup: Додає тести, рефакторинг, виправляє старі баги.
• kind/design: Повʼязане з дизайном
• kind/documentation: Додає документацію
• kind/failing-test: Тест CI постійно не проходить.
• kind/feature: Нова функціональність.
• kind/flake: Тест CI показує періодичні збої.