Kubernetes 1.33: Політика успішного виконання Job стає загальнодоступною

З випуском Kubernetes v1.33 у червні 2024 року робоча група з обробки пакетів з гордістю оголошує про досягнення загальної доступності (GA) для поля API JobsuccessPolicy. Цей етап свідчить про стабільність на рівні виробництва, зворотну сумісність API та усунення альфа/бета функціональних обмежень. Команди, які працюють з великими пакетними навантаженнями — зокрема в наукових симуляціях, AI/ML та високопродуктивних обчисленнях (HPC) — тепер можуть покладатися на successPolicy як на основний елемент для розумнішої логіки завершення Job.

Про SuccessPolicy Job

Традиційні Jobs у Kubernetes вимагають, щоб усі Pods успішно завершилися, перш ніж статус Job зміниться на Complete. У індексованих Jobs кожен Pod отримує унікальний числовий індекс у діапазоні 0..completions-1. Поле .spec.successPolicy дозволяє змінити цю поведінку “усе або нічого”, визначивши критерії для раннього виходу: або мінімальну кількість успішних індексів (succeededCount), або явний список succeededIndexes. Як тільки будь-яке з правил буде виконано, контролер Job позначає Job як успішний і запускає очищення всіх залишкових Pods.

Чому статус GA важливий

Досягнення GA означає, що API successPolicy підпадає під політику версійної несумісності Kubernetes. Не буде руйнівних змін у схемі, і гарантовано, що підтримка буде надана протягом наступних трьох незначних випусків. Для підприємств, що використовують Kubernetes у регульованих або ретельно перевірених середовищах, ця стабільність є критично важливою. Це також відкриває повну підтримку від керованих сервісів Kubernetes, таких як GKE, EKS та AKS, де альфа або бета функції можуть бути відключені або непідтримувані.

Технічні специфікації

Специфікація GA для .spec.successPolicy містить два необов’язкових підполя:

• rules[].succeededCount (ціле число): Мінімальна кількість індексованих завершень, яка потрібна.
• rules[].succeededIndexes (масив цілих чисел): Явний список індексів Pods, успіх яких викликає ранній вихід.

Всередині job-controller у kube-controller-manager спостерігає за оновленнями статусу кожного індексованого Pod. Він підтримує в пам’яті бітову карту визнаних успіхів і оцінює правила політики по черзі. Як тільки будь-яке правило повертає true, контролер додає умову SuccessCriteriaMet до статусу Job, а потім викликає вбудований API завершення Pods у Kubernetes для видалення всіх залишкових Pods.

Як це працює

Ось приклад індексованого Job з 10 Pods, який успішно завершується після завершення будь-якого з Pods:

apiVersion: batch/v1
kind: Job
metadata:
  name: example-early-exit
spec:
  parallelism: 10
  completions: 10
  completionMode: Indexed
  successPolicy:
    rules:
    - succeededCount: 1

У цій конфігурації, як тільки один Pod з будь-яким індексом завершується успішно, статус Job переходить у SuccessCriteriaMet, і всі інші Pods одразу завершуються. Для сценаріїв, де лише лідер Pod (індекс 0) визначає успіх Job, ви можете поєднати обидва поля:

spec:
  parallelism: 10
  completions: 10
  completionMode: Indexed
  successPolicy:
    rules:
    - succeededIndexes:
      - 0      # лідерський індекс
      succeededCount: 1

Реальні випадки використання та показники продуктивності

Багато великих організацій вже почали тестувати successPolicy у виробництві:

• CERN використовує індексовані Jobs для проведення параметризованих фізичних симуляцій. Завдяки ранньому виходу, коли завершується репрезентативна підмножина, вони скорочують середній час роботи кластера приблизно на 40%.
• GenomeCloud обробляє тисячі послідовувальних Jobs щодня. Використовуючи пороги succeededCount, вони зменшують витрати на обчислення та знижують щомісячні витрати на хмару на 25%.
• AI Labs Inc. організовує налаштування гіперпараметрів. Визначення мінімального кворуму успіхів у межах пришвидшує виявлення збіжності, покращуючи використання ресурсів на 30%.

Тестування показує, що додаткова логіка контролера додає менше ніж 5 мс затримки планування на подію Pod і використовує лише кілька кілобайт додаткової пам’яті в kube-controller-manager, що робить її досить легкою навіть для кластерів з обмеженими ресурсами.

Сумісність та міграційні міркування

Якщо ви використовували альфа або бета версію цієї функції (функціональні обмеження JobSuccessPolicy), для міграції на GA не потрібно змінювати версію API. Просто переконайтеся, що ваші кластери працюють на v1.33 або новішій версії, видаліть будь-які ручні перемикачі функціональних обмежень і оновіть свої маніфести Job, щоб включити successPolicy. Спадкові маніфести без successPolicy продовжать працювати як раніше, вимагаючи всі завершення.

Для автоматизації та CI-процесів оновіть будь-які kubectl apply або Helm-чарти, щоб перевірити нове поле відповідно до схеми batch/v1. Виконання kubectl explain job.spec.successPolicy покаже документацію GA після оновлення.

Погляд у майбутнє: дорожня карта та наступні кроки

На основі GA successPolicy, робоча група WG-Batch досліджує:

• Контрольні точки та відновлюваність – дозволити індексованим Jobs відновлюватися з збереженого стану після переривань або збоїв вузлів (KEP-4501).
• Координація між просторами імен – дозволити Jobs у різних просторах імен ділитися критеріями успіху через ConfigMaps або CRDs.
• TTL для Jobs з раннім виходом – автоматичне очищення Jobs, що завершуються раніше, на основі successPolicy, після налаштовуваного TTL.

Внески вітаються через репозиторій KEP та пропозиції SIG Apps.

Дізнайтеся більше

• Офіційна документація: Політика успіху
• KEP: Політика успіху/завершення Job

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

Це вдосконалення було розроблено робочою групою WG-Batch у співпраці з SIG Apps. Приєднуйтесь до обговорення на Slack, підпишіться на поштовий список робочої групи та відвідуйте двотижневі зустрічі спільноти, щоб пропонувати, переглядати чи тестувати нові функції.