Kubernetes v1.37: Представляємо стани життєвого циклу вузла
Kubernetes має багато способів описати те, що відбувається на вузлі. Готовність (readiness), taints, стан Podʼів, мітки, анотації та API конкретних провайдерів — кожен розкриває частину картини. Бракувало спільного способу, що належить Kubernetes, повідомити, що для вузла виконується drain, що він перебуває на обслуговуванні або що на ньому триває коректне вимкнення вузла.
Kubernetes v1.37 вводить пʼять загальновідомих станів вузла (Node conditions), що надають цей опис:
DrainInProgressDrainedMaintenancePlannedMaintenanceInProgressGracefulNodeShutdownInProgress
Нові стани життєвого циклу вузла
| Стан | Що він повідомляє |
|---|---|
DrainInProgress | Для вузла активно виконується drain відповідно до обраних адміністратором критеріїв drain. |
Drained | Вузол досяг обраних адміністратором критеріїв drain. |
MaintenancePlanned | Очікується, що вузол пройде через зміну в майбутньому. |
MaintenanceInProgress | Вузол перебуває в стані обслуговування. |
GracefulNodeShutdownInProgress | Визначено, що на вузлі триває коректне вимкнення вузла. |
Обслуговування може включати оновлення апаратного або програмного забезпечення, виправлення, виведення з експлуатації або налагодження. Чи потребує обслуговування drain, залежить від його впливу. Оновлення Kubernetes зазвичай слід виконувати після drain, тоді як live patch ядра може не потребувати його.
Як і інші стани вузла, кожен стан життєвого циклу використовує status для повідомлення про те, чи активне спостереження:
True: стан життєвого циклу зараз спостерігається.False: стан життєвого циклу зараз не спостерігається.Unknown: Kubernetes не може визначити, чи активний стан життєвого циклу.
reason надає стабільну, машиночитану причину для поточного статусу, а message може надати додаткові людиночитані деталі.
Наприклад, авторизований контролер обслуговування може опублікувати:
# Node .status excerpt
status:
conditions:
- type: MaintenancePlanned
status: "True"
reason: MaintenanceWindow
lastTransitionTime: "2026-12-09T12:00:00Z"
message: "Hardware maintenance is scheduled for this Node"
Що змінюється в Kubernetes v1.37
У версії v1.37 ці імена зарезервовано як загальновідомі константи NodeConditionType, а також запроваджено функціональну можливість Alpha-рівня NodeLifecycleConditions, яка типово вимкнена. У версії 1.37 ця функціональна можливість фактично нічого не робить: вона не обмежує коло користувачів, які можуть встановлювати ці стани, і жоден основний компонент їх не зчитує. Вона існує для того, щоб у майбутніх версіях можна було увімкнути заплановану вбудовану поведінку — контролери, які використовують ці стани. Вам не потрібно вмикати цю функціональну можливість, щоб почати публікувати стани вже сьогодні.
У цьому випуску за встановлення та скидання станів життєвого циклу відповідає адміністратор або авторизований адміністратором контролер.
У цьому першому випуску жоден основний контролер робочих навантажень не змінює свою поведінку на основі цих станів, але адміністратор може публікувати їх щоб повідомляти користувачам кластера про обслуговування та drain.
Як використовувати стани життєвого циклу сьогодні
Безпосередньою перевагою є чіткість операційних процесів. Адміністратори та системи автоматизації життєвого циклу можуть використовувати ці стани як загальний канал статусу для роботи з життєвим циклом вузлів, яка вже здійснюється сьогодні.
Наприклад, автоматизація обслуговування може встановити MaintenancePlanned, коли заплановане майбутнє вікно обслуговування, потім встановити MaintenanceInProgress, коли робота починається. Автоматизація drain може встановити DrainInProgress, коли починає виселяти Podʼи, і Drained, коли обрані адміністратором критерії drain виконано. Стан GracefulNodeShutdownInProgress може повідомляти, що на вузлі триває коректне вимкнення вузла.
Рекомендований шаблон — використовувати стани життєвого циклу для повідомлення статусу, тоді як операції життєвого циклу керуються через інші механізми. Продовжуйте використовувати наявні механізми Kubernetes, такі як kubectl cordon, kubectl drain,
taints та специфічні для робочих навантажень механізми для зміни поведінки планування або виселення. Використовуйте стани життєвого циклу, щоб зробити статус цієї роботи видимим для людей, дашбордів, алертів та автоматизації, яка може використовувати цей сигнал.
Встановлюючи стан, використовуйте True, поки стан життєвого циклу активний. Встановіть стан у False або видаліть його, коли стан більше не активний. Використовуйте стабільне значення reason та зрозуміле message, щоб і люди, і автоматизація могли зрозуміти, чому стан змінився. Адміністратори кластера також повинні вирішити, який компонент володіє кожним станом життєвого циклу, щоб уникнути конфліктних записів.
Чому спільний сигнал важливий
Життєвий цикл вузла впливає на компоненти по всьому кластеру. kubelet, контролер життєвого циклу вузла, контролери робочих навантажень, планувальник, засоби автоматичного масштабування, оператори сховища, та зовнішні системи обслуговування — всі потребують певного розуміння того, що відбувається з вузлом.
Сьогодні кожен компонент має реконструювати це розуміння з непрямих сигналів. Один контролер може дивитися на готовність вузла, інший — на taints, третій — на Podʼи, що завершуються або відсутні. Провайдери інфраструктури та оператори часто додають власні мітки або анотації.
Ці сигнали залишаються корисними для своїх передбачених цілей, але вони не дають відповіді на те саме питання. Наприклад, taint може впливати на планування або виселення, але не свідчить про те, що триває drain або що критерії drain адміністратора виконано. Статус вузла NotReady не пояснює, чи причиною є несподівана несправність, коректне вимкнення чи планове технічне обслуговування.
Без спільного контексту життєвого циклу компоненти, які окремо є коректними, можуть приймати суперечливі рішення. Контролер DaemonSet може замінити Pod, який kubelet навмисно завершив під час коректного вимкнення. Контролер Job може безкінечно чекати на кінцеву фазу Podʼа на вузлі, який адміністратор видаляє. Оператор системи зберігання даних може дізнатися про технічне обслуговування лише після того, як drain уже розпочався.
Нові стани надають стабільне місце на вузлі для цього відсутнього контексту як частину більших зусиль щодо покращення керування життєвим циклом вузла.
Фундамент для Kubernetes, що враховує життєвий цикл
Цінність спільного сигналу полягає в тому, хто може його використовувати — основні контролери, адміністратори або екосистема проєктів життєвого циклу. Подальші вдосконалення можуть ґрунтуватися на цих станах, без необхідності для кожного компонента розробляти власний спосіб визначення стану життєвого циклу вузла.
Розгляньмо давній граничний випадок під час rollout DaemonSet. Вузол, який зламаний або перебуває на обслуговуванні, може залишатися недоступним з причин, не повʼязаних з новою ревізією DaemonSet. Цей вузол все ще споживає бюджет доступності rollout, що може сповільнити контролер або завадити йому просувати rollout на справних вузлах.
Контролер DaemonSet знає, що Pod недоступний, але він не може сказати, чи нова ревізія провалилася чи адміністратор навмисно вивів вузол з експлуатації. Готовність, taints та стан Podʼів показують частини ситуації, але жоден не надає авторитетного контексту обслуговування.
Стан MaintenanceInProgress створює власне Kubernetes місце для публікації цього контексту. Майбутня робота може визначити, як контролер DaemonSet використовує його для порядку розгортання, обліку доступності та повідомлення статусу. Ці поведінки все ще вимагають ретельного дизайну, але мета — щоб адміністраторам більше не потрібно було вручну коригувати розгортання.
Майбутні розширення та як долучитись
Життєвий цикл вузла — це перехресна проблема. Її розвʼязання починається з того, що компоненти обмінюються достатнім контекстом для прийняття сумісних рішень. Наступний етап — спиратися на Node Lifecycle Conditions для покращення таких сценаріїв, як Graceful Node Shutdown, drain та обслуговування. Довгострокова координація життєвого циклу може вимагати явної власності, блокування та потенційно спеціалізованого API.
Екосистема Kubernetes вже включає багато рішень для обслуговування вузлів, виправлення, drain, автоматичного масштабування та керування парком вузлів. Досвід цих проєктів необхідний для побудови фундаменту, що працює в різних середовищах та операційних моделях. Node Lifecycle Working Group, SIG Node та SIG Apps запрошують супровідників та користувачів поділитися своїми випадками використання та ідеями для формування майбутньої роботи.
Слідкуйте за роботою через KEP-5683: Node Lifecycle Conditions. Для участі в наших обговореннях, приєднуйтесь до однієї з наших груп: