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

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

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

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

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

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

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

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

Основні поняття та можливості

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

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

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

Безперервне виконання

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

Виконання тільки під час завантаження

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

Звітування про стани

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

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

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

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

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

Наведене нижче правило NodeReadinessRule гарантує, що вузол залишатиметься таким, що не підлягає плануванню, доки його агент CNI не почне функціонувати. Контролер відстежує власний стан cniplugin.example.net/NetworkReady і видаляє taint 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 тільки починає свою роботу, і ми випустили перші версії. Зараз ми чекаємо на відгуки від спільноти, щоб вдосконалити план розвитку. Після плідних дискусій на Unconference під час KubeCon NA 2025 ми з радістю продовжимо розмову віч-на-віч.

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

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

• GitHub: https://sigs.k8s.io/node-readiness-controller
• Slack: долучіться до обговорення в #sig-node-readiness-controller
• Документація: Початок роботи

• ←Попередня
• Наступна→