# Kubernetes v1.37: Представляємо стан життєвого циклу вузла

LLMS index: [llms.txt](/llms.txt)

---

Kubernetes має багато способів описати те, що відбувається на Вузлі. Readiness (готовність), taints, стан Podʼів, мітки, анотації та API конкретних провайдерів кожен розкриває частину картини. Чого не вистачало — це спільного, власного Kubernetes способу казати, що Вузол [очищується](/docs/tasks/administer-cluster/safely-drain-node/), перебуває на обслуговуванні або перебуває в процесі [належного вимикання вузла](/docs/concepts/cluster-administration/node-shutdown/).

Kubernetes v1.37 вводить пʼять [станів Вузла (Node conditions)](/docs/reference/node/node-status/#condition), що надають цей опис:

- `DrainInProgress`
- `Drained`
- `MaintenancePlanned`
- `MaintenanceInProgress`
- `GracefulNodeShutdownInProgress`

## Нові стани життєвого циклу Вузла {#the-new-node-lifecycle-conditions}

| Стан | Що він повідомляє |
| --- | --- |
| `DrainInProgress` | Вузол перебуває в стані очищення відповідно до обраних адміністратором критеріїв. |
| `Drained` | Вузол досяг критеріїв очищення, обраних адміністратором. |
| `MaintenancePlanned` | Очікується, що Вузол пройде через зміну в майбутньому. |
| `MaintenanceInProgress` | Вузол перебуває в стані обслуговування. |
| `GracefulNodeShutdownInProgress` | Триває процес належного вимикання вузла. |

Обслуговування може включати оновлення апаратного або програмного забезпечення, виправлення, виведення з експлуатації або налагодження. Чи вимагає обслуговування очищення вузла, залежить від його впливу. Оновлення Kubernetes зазвичай має слідувати за очищенням, тоді як live patch ядра може не потребувати його.

Як і інші стани Вузла, кожен стан життєвого циклу використовує `status` для повідомлення про те, чи активне спостереження:

- `True`: стан життєвого циклу зараз спостерігається.
- `False`: стан життєвого циклу зараз не спостерігається.
- `Unknown`: Kubernetes не може визначити, чи активний стан життєвого циклу.

`reason` надає стабільну, машиночитану причину для поточного статусу, а `message` може надати додаткові людиночитані деталі.

Наприклад, авторизований контролер обслуговування може опублікувати:

```yaml
# 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 {#what-changes-in-kubernetes-v137}

У версії v1.37 ці імена зарезервовано як загальновідомі константи `NodeConditionType`, а також запроваджено функціональну можливість Alpha-рівня `NodeLifecycleConditions`, яка стандартно є вимкненою. У версії 1.37 ця функція фактично не виконує жодних дій: вона не обмежує коло користувачів, які можуть встановлювати ці стани, і жоден основний компонент їх не зчитує. Вона існує для того, щоб у майбутніх версіях можна було увімкнути заплановану вбудовану поведінку — контролери, які використовують ці стани. Вам не потрібно вмикати цю функцію, щоб почати публікувати стани вже сьогодні.

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

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

## Як використовувати стани життєвого циклу сьогодні {#how-to-use-lifecycle-conditions-today}

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

Наприклад, автоматизація обслуговування може встановити `MaintenancePlanned`, коли заплановане майбутнє вікно обслуговування, потім встановити `MaintenanceInProgress`, коли робота починається. Автоматизація очищення може встановити `DrainInProgress`, коли система починає витісняти Podʼи і `Drained`, коли критерії очищення, обрані адміністратором, були задоволені. Стан `GracefulNodeShutdownInProgress` може повідомляти, що процес належного завершення роботи триває на Вузлі.

Рекомендований шаблон — використовувати стани життєвого циклу для повідомлення статусу, тоді як операції життєвого циклу керуються через інші механізми. Продовжуйте використовувати наявні механізми Kubernetes, такі як [`kubectl cordon`](/docs/reference/kubectl/generated/kubectl_cordon/), [`kubectl drain`](/docs/tasks/administer-cluster/safely-drain-node/),
[taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) та специфічні для робочих навантажень механізми для зміни поведінки планування або витіснення. Використовуйте стани життєвого циклу, щоб зробити статус цієї роботи видимим для людей, дашбордів, алертів та автоматизації, яка може використовувати цей сигнал.

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

## Чому спільний сигнал важливий {#why-a-shared-signal-matters}

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

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

Ці сигнали залишаються корисними для своїх передбачених цілей, але вони не дають відповіді на питання. Наприклад, позначка «taint» може впливати на планування або витіснення, але вона не свідчить про те, що триває процес звільнення ресурсів або що критерії адміністратора щодо звільнення ресурсів виконано. Статус вузла `NotReady` не пояснює, чи причиною є несподівана несправність, планове вимкнення чи планове технічне обслуговування.

Без спільного контексту життєвого циклу компоненти, які окремо є коректними, можуть приймати суперечливі рішення. Контролер DaemonSet може замінити Pod, який `kubelet` навмисно завершив під час планового вимкнення. Контролер Job може безкінечно чекати на завершення фази Podʼа на вузлі, який адміністратор видаляє. Оператор системи зберігання даних може дізнатися про технічне обслуговування лише після того, як процес вивантаження вже розпочався.

Нові стани надають стабільне місце на Вузлі для цього відсутнього контексту як частину [більших зусиль щодо покращення управління життєвим циклом Вузла](https://kep.k8s.io/5683).

## Фундамент для Kubernetes, що враховує життєвий цикл {#the-foundation-for-lifecycle-aware-kubernetes}

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

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

Контролер DaemonSet знає, що Pod недоступний, але він не може сказати, чи нова ревізія провалилася чи адміністратор навмисно вивів Вузол з експлуатації. Готовність, taints та стан Podʼів викривають частини ситуації, але жоден не надає авторитетного контексту обслуговування.

Стан `MaintenanceInProgress` створює власне Kubernetes місце для публікації цього контексту. Майбутня робота може визначити, як контролер DaemonSet використовує його для порядку розгортання, обліку доступності та повідомлення статусу. Ці поведінки все ще вимагають ретельного дизайну, але мета — щоб адміністраторам більше не потрібно було вручну коригувати розгортання.

## Майбутні розширення та як долучитись {#future-expansions-and-getting-involved}

Життєвий цикл Вузла — це перехресна проблема. Вирішення її починається з компонентів, що використовуються достатньо контексту для прийняття сумісних рішень. Наступний етап — базуватися на Node Lifecycle Conditions для покращення сценаріїв таких як Graceful Node Shutdown, очищення та обслуговування. Довгострокова координація життєвого циклу може вимагати явної власності, блокування та потенційно спеціалізованого API.

Екосистема Kubernetes вже включає багато рішень для обслуговування Вузла, виправлення, очищення, автоматичного масштабування та управління флотом. Досвід з цими проєктами є необхідним для побудови фундаменту, що працює по-різному в середовищах та операційних моделях. Node Lifecycle Working Group, SIG Node та SIG Apps запрошують супроводжувачів та користувачів поділитися своїми випадками використання та ідеями для формування майбутньої роботи.

Слідкуйте за роботою через [KEP-5683: Node Lifecycle Conditions](https://kep.k8s.io/5683). Для участі в наших обговореннях, приєднуйтесь до однієї з наших груп:

- [Node Lifecycle Working Group](https://www.kubernetes.dev/community/community-groups/wg/node-lifecycle/)
- [SIG Node](https://www.kubernetes.dev/community/community-groups/sigs/node/)
- [SIG Apps](https://www.kubernetes.dev/community/community-groups/sigs/apps/)