Kubernetes v1.35: Job Managed By переходить у загальну доступність
У Kubernetes v1.35 можливість вказати зовнішній контролер Job (через .spec.managedBy) переходить у загальну доступність.
Ця можливість дає змогу зовнішнім контролерам повністю брати на себе узгодження Job, відкриваючи потужні моделі планування, такі як багатокластерне диспетчеризування з MultiKueue.
Навіщо делегувати узгодження Job?
Основною мотивацією для цієї можливості є підтримка архітектур багатокластерного пакетного планування, таких як MultiKueue.
Архітектура MultiKueue розрізняє кластер керування та пул робочих кластерів:
- Кластер управління відповідає за розподіл Job, але не за їх виконання. Він повинен приймати обʼєкти Job для відстеження статусу, але пропускає створення та виконання Podʼів.
- Робочі кластери отримують розподілені Job та виконують фактичні Podʼи.
- Користувачі зазвичай взаємодіють із кластером керування. Оскільки статус автоматично передається назад, вони можуть спостерігати за прогресом Job «наживо» без доступу до робочих кластерів.
- У робочих кластерах розподілені Job виконуються як звичайні Job, якими керує вбудований контролер Job, без налаштування
.spec.managedBy.
Використовуючи .spec.managedBy, контролер MultiKueue в кластері керування може взяти на себе узгодження Job. Він копіює статус із «дзеркального» Job, що виконується в робочому кластері, назад до кластера керування.
Чому б просто не вимкнути контролер Job? Хоча теоретично це можна зробити, повністю вимкнувши вбудований контролер Job, часто це неможливо або недоцільно з двох причин:
- Панелі управління, керовані постачальником: у багатьох хмарних середовищах панель управління Kubernetes заблокована, і користувачі не можуть змінювати прапорці менеджера контролерів.
- Гібридна роль кластера: користувачам часто потрібен «гібридний» режим, в якому кластер керування надсилає деякі важкі робочі навантаження до віддалених кластерів, але все одно виконує менші Job або Job, повʼязані з панеллю управління, в кластері керування.
.spec.managedByдозволяє таку деталізацію для кожного Job окремо.
Як працює .spec.managedBy
Поле .spec.managedBy вказує, який контролер відповідає за Job. Існує два режими роботи:
- Standard: якщо не встановлено або встановлено на зарезервоване значення
kubernetes.io/job-controller, вбудований контролер Job узгоджує Job як зазвичай (стандартна поведінка). - Delegation: якщо встановлено на будь-яке інше значення, вбудований контролер Job повністю пропускає узгодження для цього Job.
Щоб запобігти появі осиротілих Podʼів або витоку ресурсів, це поле є незмінним. Ви не можете перенести запущений Job з одного контролера на інший.
Якщо ви плануєте впровадити зовнішній контролер, майте на увазі, що ваш контролер повинен відповідати визначенням Job API. Для забезпечення відповідності значну частину зусиль було спрямовано на впровадження розширених правил валідації статусу Job. Перейдіть до розділу Як дізнатися більше? для отримання додаткової інформації.
Впровадження в екосистему
Поле .spec.managedBy швидко стає стандартним інтерфейсом для делегування контролю в екосистемі пакетної обробки Kubernetes.
Різні власні контролери робочого навантаження додають це поле (або його еквівалент), щоб MultiKueue міг перейняти їх узгодження та координувати їх між кластерами:
Хоча можна використовувати .spec.managedBy для реалізації власного контролера Job з нуля, ми ще не спостерігали такого. Ця можливість спеціально розроблена для підтримки моделей делегування, таких як MultiKueue, без необхідності винаходити велосипед.
Як дізнатися більше?
Якщо ви хочете дізнатися більше:
Прочитайте документацію для користувачів щодо:
Детальний огляд історії розробки:
- Пропозиція щодо вдосконалення Kubernetes (KEP) Механізм managed-by для Job, включаючи впровадження розширених правил валідації статусу Job.
- Kueue KEP для MultiKueue.
Дізнайтеся, як MultiKueue використовує .spec.managedBy на практиці, у практичному посібнику про виконання Job у кількох кластерах.
Подяки
Як і у випадку з будь-якою функцією Kubernetes, багато людей допомогли сформувати цю можливість шляхом обговорень дизайну, оглядів, тестових запусків та повідомлень про помилки.
Ми хотіли б особливо подякувати:
- Maciej Szulik — за настанови, наставництво та рецензії.
- Filip Křepinský — за настанови, наставництво та рецензії.
Приєднуйтесь
Ця робота була спонсорована Kubernetes Batch Working Group у тісній співпраці з SIG Apps та за активної підтримки спільноти SIG Scheduling.
Якщо ви зацікавлені в пакетному плануванні, рішеннях для декількох кластерів або подальшому вдосконаленні Job API:
- Приєднуйтесь до нас на засіданнях Batch WG та SIG Apps.
- Підпишіться на каналу WG Batch у Slack.