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

В Kubernetes v1.34, функція Політика заміни Pod досягла загальної доступності (GA). Ця стаття описує функцію політики заміни Pod і те, як її використовувати у ваших Jobs.

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

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

В результаті, хоча деякі Podʼи припиняють роботу, загальна кількість працюючих Podʼів для завдання може тимчасово перевищувати заданий рівень паралельності. Для індексованих Jobs це може навіть означати, що кілька 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

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

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

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

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

Ви можете перевірити, скільки 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 в тісній співпраці з SIG Apps спільнотою.

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

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