Обробка повторюваних і неповторюваних помилок Pod за допомогою політики збоїв Pod

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [stable] (стандартно увімкнено: true)

Цей документ показує, як використовувати політику збоїв Pod, у поєднанні з типовою політикою відмови Podʼа, для покращення контролю над обробкою збоїв на рівні контейнера або Pod у Job.

Визначення політики збоїв Pod може допомогти вам:

Перш ніж ви розпочнете

Ви повинні вже бути знайомі з основним використанням Job.

Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:

Версія вашого Kubernetes сервера має бути не старішою ніж v1.25.

Для перевірки версії введіть kubectl version.

Сценарії використання

Розглянемо такі сценарії використання для Завдань, які визначають політику збоїв Pod:

Використання політики збоїв Pod для уникнення непотрібних повторних запусків Podʼів

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

  1. Ознайомтесь з наступним маніфестом:

    /controllers/job-pod-failure-policy-failjob.yaml 
    apiVersion: batch/v1
kind: Job
metadata:
  name: job-pod-failure-policy-failjob
spec:
  completions: 8
  parallelism: 2
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: main
        image: docker.io/library/bash:5
        command: ["bash"]
        args:
        - -c
        - echo "Hello world! I'm going to exit with 42 to simulate a software bug." && sleep 30 && exit 42
  backoffLimit: 6
  podFailurePolicy:
    rules:
    - action: FailJob
      onExitCodes:
        containerName: main
        operator: In
        values: [42]

  2. Застосуйте маніфест%

    kubectl create -f https://k8s.io/examples/controllers/job-pod-failure-policy-failjob.yaml

  3. Через приблизно 30 секунд весь Job повинен завершитися. Перевірте статус Job, виконавши команду:

    kubectl get jobs -l job-name=job-pod-failure-policy-failjob -o yaml

    У статусі Job відображаються такі умови:

    • Умова FailureTarget: має поле reason, встановлене в PodFailurePolicy, і поле message з додатковою інформацією про завершення, наприклад, Container main for pod default/job-pod-failure-policy-failjob-8ckj8 failed with exit code 42 matching FailJob rule at index 0. Контролер Job додає цю умову, як тільки Job вважається невдалим. Для отримання деталей дивіться Завершення Job Podʼів.
    • Умова Failed: те ж саме значення для reason і message, що й в умови FailureTarget. Контролер Job додає цю умову після того, як усі Podʼи Job завершено.

    Для порівняння, якщо політика збоїв Pod була вимкнена, це б зайняло 6 спроб повторного запуску Pod, на що треба щонайменше 2 хвилини.

Прибирання

Видаліть створений Job:

kubectl delete jobs/job-pod-failure-policy-failjob

Кластер автоматично очищає Pod.

Використання політики збоїв Pod для ігнорування розладів Pod

На наступному прикладі ви можете навчитися використовувати політику збоїв Pod, щоб ігнорувати розлади Pod, які збільшують лічильник повторних спроб Pod до межі .spec.backoffLimit.

  1. Ознайомтесь з наступним маніфестом:

    /controllers/job-pod-failure-policy-ignore.yaml 
    apiVersion: batch/v1
kind: Job
metadata:
  name: job-pod-failure-policy-ignore
spec:
  completions: 4
  parallelism: 2
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: main
        image: docker.io/library/bash:5
        command: ["bash"]
        args:
        - -c
        - echo "Hello world! I'm going to exit with 0 (success)." && sleep 90 && exit 0
  backoffLimit: 0
  podFailurePolicy:
    rules:
    - action: Ignore
      onPodConditions:
      - type: DisruptionTarget

  2. Застосуйте маніфест:

    kubectl create -f https://k8s.io/examples/controllers/job-pod-failure-policy-ignore.yaml

  3. Виконайте цю команду, щоб перевірити nodeName, на якому розміщено Pod:

    nodeName=$(kubectl get pods -l job-name=job-pod-failure-policy-ignore -o jsonpath='{.items[0].spec.nodeName}')

  4. Запустить очищення вузла, щоб виселити Pod до завершення його роботи (протягом 90 секунд):

    kubectl drain nodes/$nodeName --ignore-daemonsets --grace-period=0

  5. Перевірте .status.failed, щоб переконатися, що лічильник для Job не збільшено:

    kubectl get jobs -l job-name=job-pod-failure-policy-ignore -o yaml

  6. Зніміть блокування з вузла:

    kubectl uncordon nodes/$nodeName

Job відновиться і завершиться успішно.

Для порівняння, якщо політика збоїв Pod була вимкнена, розлад Pod призведе до завершення всього Job (оскільки .spec.backoffLimit встановлено на 0).

Прибирання

Видаліть створений Job:

kubectl delete jobs/job-pod-failure-policy-ignore

Кластер автоматично очищає Pod.

Використання політики збоїв Pod для уникнення непотрібних повторних запусків Pod на основі власних станів Pod

В наступному прикладі ви можете навчитися використовувати політику збоїв Pod, щоб уникати непотрібних перезапусків Pod на основі власних станів Pod.

  1. Ознайомтесь з наступним маніфестом:

    /controllers/job-pod-failure-policy-config-issue.yaml 
    apiVersion: batch/v1
kind: Job
metadata:
  name: job-pod-failure-policy-config-issue
spec:
  completions: 8
  parallelism: 2
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: main
        image: "non-existing-repo/non-existing-image:example"
  backoffLimit: 6
  podFailurePolicy:
    rules:
    - action: FailJob
      onPodConditions:
      - type: ConfigIssue

  2. Застосуйте маніфест:

    kubectl create -f https://k8s.io/examples/controllers/job-pod-failure-policy-config-issue.yaml

    Зверніть увагу, що образ налаштоване неправильно, оскільки його не існує.

  3. Перевірте статус Pod Job, виконавши команду:

    kubectl get pods -l job-name=job-pod-failure-policy-config-issue -o yaml

    Ви побачите результат, подібний до цього:

    containerStatuses:
- image: non-existing-repo/non-existing-image:example
   ...
   state:
   waiting:
      message: Back-off pulling image "non-existing-repo/non-existing-image:example"
      reason: ImagePullBackOff
      ...
phase: Pending

    Зверніть увагу, що Pod залишається у фазі Pending, оскільки йому не вдається завантажити неправильно налаштований образ. Це, в принципі, може бути тимчасовою проблемою, і образ може бути завантажений. Однак у цьому випадку образу не існує, тому ми вказуємо на цей факт за допомогою власної умови.

  4. Додайте власну умову. Спочатку підготуйте патч, виконавши команду:

    cat <<EOF > patch.yaml
status:
  conditions:
  - type: ConfigIssue
    status: "True"
    reason: "NonExistingImage"
    lastTransitionTime: "$(date -u +"%Y-%m-%dT%H:%M:%SZ")"
EOF

    По-друге, виберіть один із Pod, створених Job, виконавши команду:

    podName=$(kubectl get pods -l job-name=job-pod-failure-policy-config-issue -o jsonpath='{.items[0].metadata.name}')

    Потім застосуйте патч до одного з Pod, виконавши наступну команду:

    kubectl patch pod $podName --subresource=status --patch-file=patch.yaml

    Якщо патч успішно застосовано, ви отримаєте повідомлення такого типу:

    pod/job-pod-failure-policy-config-issue-k6pvp patched

  5. Видаліть Pod для переходу його до фази Failed, виконавши команду:

    kubectl delete pods/$podName

  6. Перевірте статус Job, виконавши:

    kubectl get jobs -l job-name=job-pod-failure-policy-config-issue -o yaml

    У статусі Job перегляньте умову Failed з полем reason, рівним PodFailurePolicy. Додатково, поле message містить більш детальну інформацію про завершення завдання, таку як: Pod default/job-pod-failure-policy-config-issue-k6pvp має умову ConfigIssue, яка відповідає правилу FailJob за індексом 0.

Очищення

Видаліть створене вами завдання:

kubectl delete jobs/job-pod-failure-policy-config-issue

The cluster automatically cleans up the Pods.

Використання політики збоїв Pod для уникнення непотрібних повторних запусків Pod на основі індексів

Щоб уникнути непотрібних перезапусків Podʼів для кожного індексу, ви можете використовувати функції Політики збоїв Podʼа та Ліміт відстрочки для кожного індексу. У цьому розділі сторінки показано, як використовувати ці функції разом.

  1. Ознайомтесь з наступним манфіфестом:

    /controllers/job-backoff-limit-per-index-failindex.yaml 
    apiVersion: batch/v1
kind: Job
metadata:
  name: job-backoff-limit-per-index-failindex
spec:
  completions: 4
  parallelism: 2
  completionMode: Indexed
  backoffLimitPerIndex: 1
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: main
        image: docker.io/library/python:3
        command:
          # Скрипт:
          # - завершує роботу Podʼа з індексом 0 з кодом виходу 1, що призводить до однієї повторної спроби;
          # - завершує роботу Podʼа з індексом 1 з кодом виходу 42, що призводить до
          # призводить до невдачі індексу без повторної спроби.
          # - завершує роботу Podʼа з будь-яким іншим індексом.
          - python3
          - -c
          - |
            import os, sys
            index = int(os.environ.get("JOB_COMPLETION_INDEX"))
            if index == 0:
              sys.exit(1)
            elif index == 1:
              sys.exit(42)
            else:
              sys.exit(0)            
  backoffLimit: 6
  podFailurePolicy:
    rules:
    - action: FailIndex
      onExitCodes:
        containerName: main
        operator: In
        values: [42]

  2. Застосуйте маніфест:

    kubectl create -f https://k8s.io/examples/controllers/job-backoff-limit-per-index-failindex.yaml

  3. Приблизно через 15 секунд перевірте стан Podʼів для Job. Ви можете зробити це, виконавши команду:

    kubectl get pods -l job-name=job-backoff-limit-per-index-failindex -o yaml

    Ви побачите результат, подібний до цього:

    NAME                                            READY   STATUS      RESTARTS   AGE
job-backoff-limit-per-index-failindex-0-4g4cm   0/1     Error       0          4s
job-backoff-limit-per-index-failindex-0-fkdzq   0/1     Error       0          15s
job-backoff-limit-per-index-failindex-1-2bgdj   0/1     Error       0          15s
job-backoff-limit-per-index-failindex-2-vs6lt   0/1     Completed   0          11s
job-backoff-limit-per-index-failindex-3-s7s47   0/1     Completed   0          6s

    Зверніть увагу, що вивід показує наступне:

    • Два Podʼа мають індекс 0 через обмеження backoff, дозволене для однієї спроби індексування.
    • Тільки один Pod має індекс 1, оскільки код виходу невдалого Podʼа збігався з політикою збою podʼа з дією FailIndex.

  4. Перевірте стан Job виконавши:

    kubectl get jobs -l job-name=job-backoff-limit-per-index-failindex -o yaml

    У статусі Job побачите, що поле failedIndexes показує "0,1", оскільки обидва індекси зазнали невдачі. Оскільки індекс 1 не було повторено, кількість збійних Podʼів, зазначена в полі статусу "failed", дорівнює 3.

Очищення

Вилучить створений Job:

kubectl delete jobs/job-backoff-limit-per-index-failindex

Кластер автоматично очищує поди.

Альтернативи

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

Змінено April 24, 2025 at 5:18 PM PST: sync upstream (03e4e921ba)