Kubernetes v1.34: Політика заміни Podʼів для Job переходить у GA

У Kubernetes v1.34 можливість політики заміни Podʼів досягла загальної доступності (GA). Ця стаття описує політику заміни Podʼів і те, як її використовувати у ваших Job.

Про політику заміни Podʼів

Типово контролер Job негайно відтворює Podʼи, як тільки вони виходять з ладу або починають завершувати роботу (коли вони мають мітку часу видалення).

У результаті, поки деякі Podʼи завершуються, загальна кількість працюючих Podʼів для Job може тимчасово перевищувати заданий рівень паралельності. Для індексованих Job це може навіть означати, що кілька Podʼів працюють для одного й того ж індексу одночасно.

Ця поведінка добре працює для багатьох робочих навантажень, але в певних випадках може викликати проблеми.

Наприклад, популярні фреймворки машинного навчання, такі як TensorFlow та JAX, очікують, що для кожного індексу виконавця буде точно один Pod. Якщо два Podʼи працюють одночасно, ви можете зіткнутися з такими помилками:

/job:worker/task:4: Duplicate task registration with task_name=/job:worker/replica:0/task:4

Крім того, запуск замінних Podʼів до повного завершення старих може призвести до:

• Затримок у плануванні з боку kube-scheduler, оскільки вузли залишаються зайнятими.
• Непотрібного масштабування кластера для розміщення замінних Podʼів.
• Тимчасового обходу перевірок квот з боку оркестраторів робочих навантажень, таких як Kueue.

З політикою заміни Podʼів Kubernetes надає вам контроль над тим, коли панель управління замінює Podʼи, що завершуються, допомагаючи уникнути цих проблем.

Як працює політика заміни Podʼів

Це вдосконалення означає, що Job у Kubernetes мають необовʼязкове поле .spec.podReplacementPolicy. Ви можете вибрати одну з двох політик:

• TerminatingOrFailed (типово): Замінює Podʼи, щойно вони починають завершуватися.
• Failed: Замінює Podʼи лише після того, як вони повністю завершаться і перейдуть у фазу Failed.

Встановлення політики на Failed забезпечує створення нового Podʼа лише після повного завершення попереднього.

Для Job з політикою відмови Podʼів (Pod Failure Policy) типове значення для podReplacementPolicy — Failed, і жодне інше значення не дозволяється. Дивіться Політика відмови Podʼів, щоб дізнатися більше про політики відмови Podʼів для Job.

Ви можете перевірити, скільки Podʼів наразі завершуються, перевіривши поле .status.terminating Job:

kubectl get job myjob -o=jsonpath='{.status.terminating}'

Приклад

Ось приклад Job, який виконує завдання двічі (spec.completions: 2) паралельно (spec.parallelism: 2) і замінює Podʼи лише після їх повного завершення (spec.podReplacementPolicy: Failed):

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  completions: 2
  parallelism: 2
  podReplacementPolicy: Failed
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: worker
        image: your-image

Якщо Pod отримує сигнал SIGTERM (видалення, виселення, витіснення…), він починає завершувати роботу. Коли контейнер обробляє завершення роботи належним чином, очищення може зайняти деякий час.

Коли Job починається, ми побачимо два Podʼи, які працюють:

kubectl get pods

NAME                READY   STATUS    RESTARTS   AGE
example-job-qr8kf   1/1     Running   0          2s
example-job-stvb4   1/1     Running   0          2s

Видалимо один з Podʼів (example-job-qr8kf).

З політикою TerminatingOrFailed, як тільки один Pod (example-job-qr8kf) починає завершуватися, контролер Job негайно створює новий Pod (example-job-b59zk) для його заміни.

kubectl get pods

NAME                READY   STATUS        RESTARTS   AGE
example-job-b59zk   1/1     Running       0          1s
example-job-qr8kf   1/1     Terminating   0          17s
example-job-stvb4   1/1     Running       0          17s

З політикою Failed, новий Pod (example-job-b59zk) не створюється, поки старий Pod (example-job-qr8kf) завершує свою роботу.

kubectl get pods

NAME                READY   STATUS        RESTARTS   AGE
example-job-qr8kf   1/1     Terminating   0          17s
example-job-stvb4   1/1     Running       0          17s

Коли Pod, що завершується, повністю переходить у фазу Failed, створюється новий Pod:

kubectl get pods

NAME                READY   STATUS        RESTARTS   AGE
example-job-b59zk   1/1     Running       0          1s
example-job-stvb4   1/1     Running       0          25s

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

• Ознайомтесь з документацією для користувачів про Політику заміни Podʼів, Ліміт повторних спроб для кожного індексу, та Політику відмови Podʼів.
• Ознайомтесь з KEP для Політики заміни Podʼів, Ліміту повторних спроб для кожного індексу, та Політики відмови Podʼів.

Подяки

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

Оскільки ця можливість переходить у стабільний стан після 2 років, ми хотіли б подякувати таким людям:

• Kevin Hannon - за написання KEP та початкову реалізацію.
• Michał Woźniak - за настанови, менторство та рецензії.
• Aldo Culquicondor - за настанови, менторство та рецензії.
• Maciej Szulik - за настанови, менторство та рецензії.
• Dejan Zele Pejchev - за те, що взяв на себе цю можливість та просував її з Alpha через Beta до GA.

Долучайтесь

Цю роботу спонсорувала batch working group Kubernetes у тісній співпраці зі спільнотою SIG Apps.

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

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