如何确保我的 cronjob 作业不会重试失败？

Question

我有一个在 GKE 上运行并运行 Cucumber JVM 测试的 Kubernetes Cronjob。如果由于断言失败、某些资源不可用等原因导致 Step 失败，Cucumber 会正确抛出异常，导致 Cronjob 作业失败，并且 Kubernetes pod 的状态更改为ERROR。这会导致创建一个新的 pod，它会尝试再次运行相同的 Cucumber 测试，但会再次失败并再次重试。

我不希望发生任何这些重试。如果 Cronjob 作业失败，我希望它保持失败状态并且根本不重试。基于this，我已经尝试将backoffLimit: 0 与restartPolicy: Never 与concurrencyPolicy: Forbid 结合使用，但它仍然通过创建新的pod 并再次运行测试来重试。

我错过了什么？这是我的 Cronjob 的 kube 清单：

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: quality-apatha
  namespace: default
  labels:
    app: quality-apatha
spec:
  schedule: "*/1 * * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      backoffLimit: 0
      template:
        spec:
          containers:
            - name: quality-apatha
              image: FOO-IMAGE-PATH
              imagePullPolicy: "Always"
              resources:
                limits:
                  cpu: 500m
                  memory: 512Mi
              env:
                - name: FOO
                  value: BAR
              volumeMounts:
                - name: FOO
                  mountPath: BAR
              args:
                - java
                - -cp
                - qe_java.job.jar:qe_java-1.0-SNAPSHOT-tests.jar
                - org.junit.runner.JUnitCore
                - com.liveramp.qe_java.RunCucumberTest
          restartPolicy: Never
          volumes:
            - name: FOO
              secret:
                secretName: BAR

还有其他 Kubernetes Kind 可以用来停止重试吗？

谢谢！

Answer 1

为了使事情尽可能简单，我使用官方 kubernetes 文档中的 this 示例对其进行了测试，对其进行了微小的修改以说明在不同场景中实际发生的情况。

我可以确认，当 backoffLimit 设置为 0 和 restartPolicy 设置为 Never 一切都按预期工作并且没有重试。请注意，在您的示例中，Job 的每次运行都计划以 60 秒的间隔运行 (schedule: "*/1 * * * *")不被视为重试。。 p>

让我们仔细看看下面的例子（base yamlavialable here）：

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      backoffLimit: 0
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - non-existing-command
          restartPolicy: Never

它根据schedule 生成新的cron 作业every 60 seconds，无论它失败还是运行成功。在这个特定示例中，它被配置为失败，因为我们试图运行 non-existing-command。

你可以通过运行来检查发生了什么：

$ kubectl get pods
NAME                     READY   STATUS              RESTARTS   AGE
hello-1587558720-pgqq9   0/1     Error               0          61s
hello-1587558780-gpzxl   0/1     ContainerCreating   0          1s

如您所见，没有重试。尽管第一个Pod 失败了，但根据我们的规范，新的会在 60 秒后准确生成。我想再次强调一下。 这不是重试。

另一方面，当我们修改上面的例子并设置backoffLimit: 3时，我们可以观察到重试次数。如您所见，现在创建新的Pods比每 60 秒更频繁。 这是重试。

$ kubectl get pods
NAME                     READY   STATUS   RESTARTS   AGE
hello-1587565260-7db6j   0/1     Error    0          106s
hello-1587565260-tcqhv   0/1     Error    0          104s
hello-1587565260-vnbcl   0/1     Error    0          94s
hello-1587565320-7nc6z   0/1     Error    0          44s
hello-1587565320-l4p8r   0/1     Error    0          14s
hello-1587565320-mjnb6   0/1     Error    0          46s
hello-1587565320-wqbm2   0/1     Error    0          34s

上面我们可以看到3 次重试（Pod 创建尝试），与hello-1587565260 job 和4 次重试 相关（包括与hello-1587565320job相关的未计入backoffLimit: 3的原始第一次尝试。

如您所见，作业本身仍按计划运行，以 60 秒的间隔：

kubectl get jobs
NAME               COMPLETIONS   DURATION   AGE
hello-1587565260   0/1           2m12s      2m12s
hello-1587565320   0/1           72s        72s
hello-1587565380   0/1           11s        11s

但是由于我们的 backoffLimit 将此时间设置为 3，每次负责运行作业的 Pod 失败时，会发生 3 次额外重试。

我希望这有助于消除关于在 kubernetes 中运行 cronJobs 的任何可能的困惑。

如果您对只运行一次而不是定期运行某项感兴趣，请查看简单的 Job 而不是 CronJob。

如果您仍想定期运行此特定作业，但假设每 24 小时运行一次，而不是每分钟一次，请考虑更改您的 Cron 配置。