Kubernetes 1.37 отримав спільні сигнали для drain, обслуговування та завершення вузлів

Kubernetes 1.37 вводить п’ять стандартизованих станів життєвого циклу Node, щоб кластер міг прямо повідомляти про drain, планове обслуговування або контрольоване завершення роботи. Раніше різні контролери намагалися відновити цей контекст із readiness, taints, станів Pod, labels та provider-specific API. Через це одна й та сама ситуація могла трактуватися по-різному.

П’ять нових умов

DrainInProgress означає, що вузол активно звільняють відповідно до критеріїв адміністратора. Drained повідомляє, що ці критерії вже виконано. MaintenancePlanned описує заплановану майбутню зміну, а MaintenanceInProgress — обслуговування, яке вже відбувається. П’ятий стан, GracefulNodeShutdownInProgress, сигналізує про контрольоване завершення роботи Node.

Як і звичайний Node condition, кожен запис має status зі значенням True, False або Unknown. Поле reason повинно містити стабільну машинозчитувану причину, а message — додаткове пояснення для оператора. Обслуговування може означати hardware rollout, оновлення ПЗ, remediation, виведення обладнання з експлуатації або debugging.

Що реально працює у версії 1.37

Назви зарезервовано як well-known NodeConditionType, а feature gate NodeLifecycleConditions має статус Alpha і вимкнений за замовчуванням. Проте в цьому релізі gate фактично не змінює поведінку: він не обмежує, хто записує умови, і жоден core-компонент ще не приймає на їхній основі автоматичних рішень.

Адміністратор або уповноважений controller сам відповідає за встановлення й очищення станів. Умови вже можна публікувати без увімкнення feature gate, але вони є каналом спостереження, а не командою. MaintenanceInProgress=True не виконає cordon, не виселить Pod і не зупинить scheduler.

Не заміна cordon, drain і taints

Проєкт рекомендує й надалі використовувати наявні механізми для дії: kubectl cordon, kubectl drain, taints і workload-specific controls. Lifecycle conditions мають зробити стан цієї роботи видимим для людей, dashboards, alerts та зовнішньої автоматизації.

Наприклад, maintenance controller може спочатку виставити MaintenancePlanned, на початку вікна змінити його на MaintenanceInProgress, а drain automation — послідовно опублікувати DrainInProgress і Drained. Коли стан перестає бути актуальним, condition потрібно перевести у False або видалити. Для кожної умови слід призначити одного власника, інакше два контролери можуть перезаписувати статус один одного.

Чому непрямої діагностики недостатньо

NotReady не пояснює, чи вузол аварійно впав, проходить graceful shutdown або перебуває на плановому ремонті. Taint впливає на scheduling чи eviction, але не підтверджує, що drain справді триває або завершився за визначеними критеріями. У результаті незалежно коректні компоненти можуть ухвалювати суперечливі рішення.

Один із прикладів — DaemonSet rollout. Вузол, недоступний через обслуговування, продовжує споживати availability budget і може блокувати оновлення здорових Node. DaemonSet controller бачить недоступний Pod, але не знає, чи проблема у новій ревізії, чи вузол навмисно виведено з роботи. MaintenanceInProgress створює стандартне місце для такого контексту, хоча алгоритми реакції ще мають бути спроєктовані в наступних релізах.

Практичне впровадження

• Визначити controller-власник кожного condition і правила очищення.
• Не змінювати scheduling лише через новий сигнал без окремої перевіреної автоматизації.
• Додати conditions до dashboards і alerts, зберігши наявні метрики readiness та Pod lifecycle.
• У reason використовувати стабільні значення, а не довільні описи оператора.
• Спочатку протестувати інтеграцію на non-production pool і сценаріях interrupted maintenance.

Головне обмеження: у Kubernetes 1.37 це фундамент для lifecycle-aware поведінки, а не завершена система оркестрації maintenance. Користь уже є для observability та узгодження зовнішніх контролерів, але автоматичні реакції потребують власної логіки й уважного контролю доступу до Node.status.