Представляємо контролер готовності вузлів

Автор: Ajay Sundar Karuppasamy (Google) | Перекладач(і): Андрій Головін |
Логотип контролера готовності вузла

У стандартній моделі Kubernetes придатність вузла для робочих навантажень залежить від єдиного бінарного стану «Ready» («Готовий»). Однак у сучасних середовищах Kubernetes вузли потребують складних інфраструктурних залежностей, таких як мережеві агенти, драйвери сховищ, прошивка GPU або спеціальні перевірки працездатності, щоб бути повністю готовими до роботи, перш ніж вони зможуть надійно обслуговувати поди.

Сьогодні від імені проєкту Kubernetes я оголошую про запуск Node Readiness Controller. Цей проєкт впроваджує декларативну систему для управління позначками вузлів, розширюючи захисні барʼєри готовності під час завантаження вузлів за межі стандартних станів. Динамічно керуючи taints на основі спеціальних сигналів стану, контролер гарантує, що робочі навантаження розміщуються тільки на вузлах, які відповідають усім вимогам інфраструктури.

Навіщо потрібен контролер готовності вузлів?

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

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

Він надає три основні переваги:

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

Основні поняття та функції

Контролер базується на API NodeReadinessRule (NRR), який дозволяє визначати декларативні gate для ваших вузлів.

Гнучкі режими виконання

Контролер підтримує два різних режими роботи:

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

Звіт про стан

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

  • Node Problem Detector (NPD): використовуйте наявні налаштування NPD та власні скрипти для звітування про стан вузлів.
  • Readiness Condition Reporter: легкий агент, наданий проєктом, який можна розгорнути для періодичної перевірки локальних HTTP точок доступу та відповідного виправлення стану вузлів.

Операційна безпека з тестовим запуском

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

Приклад: ініціалізація CNI

Наступне правило NodeReadinessRule гарантує, що вузол залишатиметься таким, що не підлягає плануванню, доки його агент CNI не почне функціонувати. Контролер відстежує спеціальну умову cniplugin.example.net/NetworkReady і видаляє позначку readiness.k8s.io/acme.com/network-unavailable лише тоді, коли статус стає True.

apiVersion: readiness.node.x-k8s.io/v1alpha1
kind: NodeReadinessRule
metadata:
  name: network-readiness-rule
spec:
  conditions:
    - type: "cniplugin.example.net/NetworkReady"
      requiredStatus: "True"
  taint:
    key: "readiness.k8s.io/acme.com/network-unavailable"
    effect: "NoSchedule"
    value: "pending"
  enforcementMode: "bootstrap-only"
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker: ""

Демо:

Приєднуйтесь

Node Readiness Controller тільки починає свою роботу, і ми випустили перші версії [https://github.com/kubernetes-sigs/node-readiness-controller/releases/tag/v0.1.1). Зараз ми чекаємо на відгуки від спільноти, щоб вдосконалити план розвитку. Після плідних дискусій на Unconference під час KubeCon NA 2025 ми з радістю продовжимо розмову віч-на-віч.

Приєднуйтесь до нас на KubeCon + CloudNativeCon Europe 2026 на сесії для розробників: Вирішення проблеми недетермінованого планування: представлення Node Readiness Controller.

Тим часом ви можете долучитися до нашої роботи або стежити за нашими досягненнями тут: