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

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

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

• краще використовувати обчислювальні ресурси, уникаючи непотрібних повторних запусків Podʼів.
• уникати збоїв Job через збої Pod (такі як випередження, виселення ініційоване API або виселення на основі taint).

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

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

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

• iximiuz Labs
• Killercoda
• KodeKloud
• Play with Kubernetes

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

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

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

• Уникнення непотрібних повторних спроб запуску Podʼів
• Ігнорування розладів у роботі Podʼів
• Уникнення непотрібних повторних спроб запуску Podʼів на основі власних станів Podʼів
• Уникнення непотрібних повторних спроб запуску 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ʼа була б вимкнено, Job повторював би спроби до досягнення backoffLimit (6 відмов). Оскільки повторні спроби використовують експоненціальне відхилення, а з parallelism: 2 відмови відбуваються парами, затримка між спробами збільшується з кожною повторною спробою. Як результат, у цьому прикладі знадобилося б щонайменше 9 хвилин, перш ніж Job зазнав би невдачі.

Прибирання

Видаліть створений 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ʼів.