Обробка повторюваних і неповторюваних помилок Pod за допомогою політики збоїв Pod
Kubernetes v1.26 [beta]Цей документ показує, як використовувати політику збоїв Pod, у поєднанні з типовою політикою відмови Podʼа, для покращення контролю над обробкою збоїв на рівні контейнера або Pod у Job.
Визначення політики збоїв Pod може допомогти вам:
- краще використовувати обчислювальні ресурси, уникаючи непотрібних повторних запусків Pod.
- уникати збоїв Job через збої Pod (такі як випередження, виселення ініційоване API або виселення на основі taint).
Перш ніж ви розпочнете
Ви повинні вже бути знайомі з основним використанням Job.
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Версія вашого Kubernetes сервера має бути не старішою ніж v1.25. Для перевірки версії введітьkubectl version.Переконайтеся, що feature gates
PodDisruptionConditions і JobPodFailurePolicy увімкнені у вашому кластері.
Використання політики збоїв Pod для уникнення непотрібних повторних запусків Pod
В наступному прикладі ви можете навчитися використовувати політику збоїв Pod, щоб уникати непотрібних перезапусків Pod, коли збій Pod вказує на неповторювану помилку програмного забезпечення.
Спочатку створіть Job на основі конфігурації:
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]
виконавши команду:
kubectl create -f job-pod-failure-policy-failjob.yaml
Через приблизно 30 секунд весь Job повинен завершитися. Перевірте статус Job, виконавши команду:
kubectl get jobs -l job-name=job-pod-failure-policy-failjob -o yaml
У статусі Job побачите умову Failed із полем reason рівним PodFailurePolicy. Крім того, поле message містить детальнішу інформацію про завершення Job, наприклад: Container main for pod default/job-pod-failure-policy-failjob-8ckj8 failed with exit code 42 matching FailJob rule at index 0.
Для порівняння, якщо політика збоїв Pod була вимкнена, це б зайняло 6 спроб повторного запуску Pod, на що треба щонайменше 2 хвилини.
Прибирання
Видаліть створений Job:
kubectl delete jobs/job-pod-failure-policy-failjob
Кластер автоматично очищає Pod.
Використання політики збоїв Pod для ігнорування розладів Pod
На наступному прикладі ви можете навчитися використовувати політику збоїв Pod, щоб ігнорувати розлади Pod, які збільшують лічильник повторних спроб Pod до межі .spec.backoffLimit.
Увага:
Час має значення для цього прикладу, тому вам слід прочитати про кроки перед їх виконанням. Щоб викликати розлад Podʼа, важливо запустити очищення вузла, поки Pod працює на ньому (протягом 90 секунд після розміщення Pod).Створіть Job на основі конфігурації:
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виконавши команду:
kubectl create -f job-pod-failure-policy-ignore.yamlВиконайте цю команду, щоб перевірити
nodeName, на якому розміщено Pod:nodeName=$(kubectl get pods -l job-name=job-pod-failure-policy-ignore -o jsonpath='{.items[0].spec.nodeName}')Запустить очищення вузла, щоб виселити Pod до завершення його роботи (протягом 90 секунд):
kubectl drain nodes/$nodeName --ignore-daemonsets --grace-period=0Перевірте
.status.failed, щоб переконатися, що лічильник для Job не збільшено:kubectl get jobs -l job-name=job-pod-failure-policy-ignore -o yamlЗніміть блокування з вузла:
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.27, оскільки він базується на переході видалених Pod з фазиPending до термінальної фази (див. Фази Pod).Спочатку створіть Job на основі конфігурації:
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виконавши команду:
kubectl create -f job-pod-failure-policy-config-issue.yamlЗверніть увагу, що образ налаштоване неправильно, оскільки його не існує.
Перевірте статус 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, оскільки йому не вдається завантажити неправильно налаштований образ. Це, в принципі, може бути тимчасовою проблемою, і образ може бути завантажений. Однак у цьому випадку образу не існує, тому ми вказуємо на цей факт за допомогою власної умови.Додайте власну умову. Спочатку підготуйте патч, виконавши команду:
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Видаліть Pod для переходу його до фази
Failed, виконавши команду:kubectl delete pods/$podNameПеревірте статус 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.
Примітка:
В операційному середовищі кроки 3 та 4 повинні бути автоматизовані контролером, наданим користувачем.Очищення
Видаліть створене вами завдання:
kubectl delete jobs/job-pod-failure-policy-config-issue
Кластер автоматично очищує поди.
Альтернативи
Ви можете покладатись виключно на політику відмови Pod backoff, вказавши поле .spec.backoffLimit завдання. Однак у багатьох ситуаціях важко знайти баланс між встановленням низького значення для .spec.backoffLimit для уникнення непотрібних повторних спроб виконання Podʼів, але достатньо великого, щоб забезпечити, що Job не буде припинено через втручання у роботу Podʼів.