如果 Kubernetes 作业被逐出，则重新启动，但如果失败则不重新启动？

Question

我正在使用自动缩放 Kubernetes 集群。如果

Job

的 pod 运行在未充分利用的节点上，则该节点将被销毁，作业的 pod 将被驱逐。

我希望作业的 pod 在被驱逐时开始在另一个节点上运行，因为它尝试运行的节点已被破坏。但是，如果容器以非零退出代码退出，或者超出其资源限制，我不希望作业重新启动。 （通常在我的环境中，非零退出代码或限制耗尽意味着作业无法成功，并且我不希望我的集群扩展得比运行所有这些重新启动所需的时间更大，从而浪费计算.) 这可能吗？

我对文档的阅读是，有一个由

backoffLimit

设置的 Pod 娱乐池。看起来，虽然您可以设置

OnFailure

 重新启动策略以就地重新运行，而不消耗这些，但如果容器中的代码失败，您无法阻止作业在返回时重新启动最多 

backoffLimit

 次失败。如果 pod 达到了 

backoffLimit

，那么它看起来也不会在驱逐后重新启动。

我认为在 K8 的未来版本（1.26 的 beta 版）中这可能是可能的。请参阅下面的示例，其中它忽略了由于少量驱逐而导致的失败。

Answer 1

更多信息：

https://kubernetes.io/docs/concepts/workloads/controllers/job/#pod-failure-policy

apiVersion: batch/v1
kind: Job
metadata:
  name: job-pod-failure-policy-example
spec:
  completions: 12
  parallelism: 3
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: main
        image: docker.io/library/bash:5
        command: ["bash"]        # example command simulating a bug which triggers the FailJob action
        args:
        - -c
        - echo "Hello world!" && sleep 5 && exit 42
  backoffLimit: 6
  podFailurePolicy:
    rules:
    - action: FailJob
      onExitCodes:
        containerName: main      # optional
        operator: In             # one of: In, NotIn
        values: [42]
    - action: Ignore             # one of: Ignore, FailJob, Count
      onPodConditions:
      - type: DisruptionTarget   # indicates Pod disruption