Kubernetes v1.35: Завдання керовані зовнішніми контролерами переходять у загальну доступність

Автор: Dejan Zele Pejchev (G-Research), Michał Woźniak (Google) | Перекладач(і): Андрій Головін |

У Kubernetes v1.35 можливість вказати зовнішній контролер Завдань (через .spec.managedBy) переходить у загальну доступність.

Ця функція дозволяє зовнішнім контролерам брати на себе повну відповідальність за узгодження Завдань (Job), відкриваючи потужні моделі планування, такі як багатокластерне диспетчеризування з MultiKueue.

Навіщо делегувати узгодження Завдань?

Основною мотивацією для цієї функції є підтримка архітектур багатокластерного пакетного планування, таких як MultiKueue.

Архітектура MultiKueue розрізняє кластер управління та пул робочих кластерів:

  • Кластер управління відповідає за розподіл завдань, але не за їх виконання. Він повинен приймати обʼєкти Job для відстеження статусу, але пропускає створення та виконання Podʼів.
  • Кластери робочих вузлів отримують розподілені Завдання та виконують фактичні Podʼи.
  • Користувачі зазвичай взаємодіють із кластером управління. Оскільки статус автоматично передається назад, вони можуть спостерігати за прогресом Завдання «наживо» без доступу до кластерів робочих вузлів.
  • У робочих кластерах розподілені Завдання виконуються як звичайні Завдання, що управляються вбудованим контролером Завдань, без налаштування .spec.managedBy.

Використовуючи .spec.managedBy, контролер MultiKueue в кластері управління може взяти на себе узгодження Завдання. Він копіює статус із «дзеркального» Завдання, що виконується в робочому кластері, назад до кластера управління.

Чому б просто не вимкнути контролер завдань? Хоча теоретично це можна зробити, повністю вимкнувши вбудований контролер Завдань, часто це неможливо або недоцільно з двох причин:

  1. Панелі управління, керовані постачальником: у багатьох хмарних середовищах панель управління Kubernetes заблокована, і користувачі не можуть змінювати прапорці менеджера контролера.
  2. Гібридна роль кластера: користувачам часто потрібен «гібридний» режим, в якому кластер управління надсилає деякі важкі робочі навантаження до віддалених кластерів, але все одно виконує менші завдання або завдання, повʼязані з панеллю управління, в кластері управління. .spec.managedBy дозволяє таку деталізацію для кожного завдання окремо.

Як працює .spec.managedBy

Поле .spec.managedBy вказує, який контролер відповідає за Завдання. Існує два режими роботи:

  • Standard: якщо не встановлено або встановлено на зарезервоване значення kubernetes.io/job-controller, вбудований контролер Job узгоджує завдання як зазвичай (стандартна поведінка).
  • Delegation: якщо встановлено на будь-яке інше значення, вбудований контролер Job повністю пропускає узгодження для цього завдання.

Щоб запобігти появі осиротілих Podʼів або витоку ресурсів, це поле є незмінним. Ви не можете перенести запущене завдання з одного контролера на інший.

Якщо ви плануєте впровадити зовнішній контролер, майте на увазі, що ваш контролер повинен відповідати визначенням Job API. Для забезпечення відповідності значну частину зусиль було спрямовано на впровадження розширених правил перевірки статусу завдання. Перейдіть до розділу Як дізнатися більше? для отримання додаткової інформації.

Впровадження в екосистему

Поле .spec.managedBy швидко стає стандартним інтерфейсом для делегування контролю в екосистемі пакетної обробки Kubernetes.

Різні власні контролери робочого навантаження додають це поле (або його еквівалент), щоб MultiKueue міг перейняти їх узгодження та координувати їх між кластерами:

Хоча можна використовувати .spec.managedBy для реалізації власного контролера завдань з нуля, ми ще не спостерігали такого. Ця функція спеціально розроблена для підтримки моделей делегування, таких як MultiKueue, без необхідності винаходити велосипед.

Як дізнатися більше?

Якщо ви хочете дізнатися більше:

Прочитайте документацію для користувачів щодо:

Детальний огляд історії розробки:

Дізнайтеся, як MultiKueue використовує .spec.managedBy на практиці, у посібнику з виконання завдань для виконання завдань у кластерах.

Подяки

Як і у випадку з будь-якою функцією Kubernetes, багато людей допомогли сформувати цю функцію шляхом обговорень дизайну, оглядів, тестових запусків та повідомлень про помилки.

Ми хотіли б особливо подякувати:

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

Ця робота була спонсорована Kubernetes Batch Working Group у тісній співпраці з SIG Apps та за активної підтримки спільноти SIG Scheduling.

Якщо ви зацікавлені в пакетному плануванні, рішеннях для декількох кластерів або подальшому вдосконаленні Job API:

  • Приєднуйтесь до нас на засіданнях Batch WG та SIG Apps.
  • Підпишіться на WG Batch Slack channel.