使用 Pod 失效策略处理可重试和不可重试的 Pod 失效
本文向你展示如何结合默认的 Pod 回退失效策略来使用 , 以改善 Job 内处理容器级别或 Pod 级别的失效。
Pod 失效策略的定义可以帮助你:
- 避免不必要的 Pod 重试,以更好地利用计算资源。
- 避免由于 Pod 干扰(例如、 API 发起的驱逐或基于的驱逐) 而造成的 Job 失败。
你应该已熟悉了 的基本用法。
你必须拥有一个 Kubernetes 的集群,同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 建议在至少有两个节点的集群上运行本教程,且这些节点不作为控制平面主机。 如果你还没有集群,你可以通过 Minikube 构建一个你自己的集群,或者你可以使用下面任意一个 Kubernetes 工具构建:
你的 Kubernetes 服务器版本必须是 v1.25. 要获知版本信息,请输入 kubectl version
.
说明:
因为这些特性还处于 Alpha 阶段,所以在准备 Kubernetes 集群时要启用两个: JobPodFailurePolicy
和 PodDisruptionsCondition
。
借用以下示例,你可以学习在 Pod 失效表明有一个不可重试的软件漏洞时如何使用 Pod 失效策略来避免不必要的 Pod 重启。
首先,基于配置创建一个 Job:
运行以下命令:
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 失效策略被禁用,将会让 Pod 重试 6 次,用时至少 2 分钟。
删除你创建的 Job:
集群自动清理这些 Pod。
通过以下示例,你可以学习如何使用 Pod 失效策略将 Pod 重试计数器朝着 .spec.backoffLimit
限制递增来忽略 Pod 干扰。
注意:
这个示例的时机比较重要,因此你可能需要在执行之前阅读这些步骤。 为了触发 Pod 干扰,重要的是在 Pod 在其上运行时(自 Pod 调度后的 90 秒内)腾空节点。
-
apiVersion: batch/v1
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
backoffLimit: 0
podFailurePolicy:
rules:
- action: Ignore
onPodConditions:
- type: DisruptionTarget
运行以下命令:
kubectl create -f job-pod-failure-policy-ignore.yaml
运行以下这条命令检查将 Pod 调度到的
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
解除节点的保护:
Job 恢复并成功完成。
为了比较,如果 Pod 失效策略被禁用,Pod 干扰将使得整个 Job 终止(随着 .spec.backoffLimit
设置为 0)。
清理
删除你创建的 Job:
kubectl delete jobs/job-pod-failure-policy-ignore
通过指定 Job 的 字段,你可以完全依赖 Pod 回退失效策略。 然而在许多情况下,难题在于如何找到一个平衡,为 .spec.backoffLimit
设置一个较小的值以避免不必要的 Pod 重试, 或者设置一个足够大的值以确保 Job 不会因 Pod 干扰而终止。