Question

不确定我做错了什么，但是我遇到了一个问题，即CronJobs停止安排新的Jobs。看来只是在几次失败后才能启动新Job。在我的特定情况下，乔布斯无法启动容器图像，因此无法启动。

我并没有真正找到任何可以导致这种情况的设置，但是我不是Kubernetes CronJobs的专家。下面的配置：

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  labels:
    app.kubernetes.io/instance: cron-deal-report
    app.kubernetes.io/managed-by: Tiller
    app.kubernetes.io/name: cron
    helm.sh/chart: cron-0.1.0
  name: cron-deal-report
spec:
  concurrencyPolicy: Forbid
  failedJobsHistoryLimit: 1
  jobTemplate:
    metadata:
      creationTimestamp: null
    spec:
      template:
        spec:
          containers:
          - args:
            - -c
            - npm run script
            command:
            - /bin/sh
            env:
            image: <redacted>
            imagePullPolicy: Always
            name: cron
            resources: {}
            securityContext:
              runAsUser: 1000
            terminationMessagePath: /dev/termination-log
            terminationMessagePolicy: File
          dnsPolicy: ClusterFirst
          restartPolicy: Never
          schedulerName: default-scheduler
          securityContext: {}
          terminationGracePeriodSeconds: 30
  schedule: 0/15 * * * *
  successfulJobsHistoryLimit: 3
  suspend: false
status: {}

Answer 1

kubernetes作业如何处理故障

根据Jobs - Run to Completion - Handling Pod and Container Failures：

整个Pod可能也会失败，原因有很多，例如 pod已从节点启动（节点已升级，重新引导，删除，等等），或者容器的容器发生故障，并且 .spec.template.spec.restartPolicy = "Never" 。当Pod发生故障时， Job控制器将启动一个新的Pod。

您将restartPolicy: Never用于jobTemplate，因此，请参见Pod backoff failure policy下的引号：

在某些情况下，您想要在完成一定数量的工作后失败由于配置等逻辑错误而重试。为此，请设置 .spec.backoffLimit在考虑之前指定重试次数作业失败。 回退限制默认设置为6 。如果在作业的下一个状态检查之前没有新的失败Pod出现，则会重置退避计数。

.spec.backoffLimit中没有定义jobTemplate，因此它使用默认值（6）。

根据Job Termination and Cleanup，以下内容：

默认情况下，除非Pod失败，否则Job会不间断运行将作业推迟至上述.spec.backoffLimit。终止工作的另一种方法是设置有效期限。通过将作业的.spec.activeDeadlineSeconds字段设置为秒数来执行此操作。

这是您的情况：如果您的容器连续六次未能提取图像，则您的作业将被视为失败。

Cronjobs

根据Cron Job Limitations：

cron作业在其计划的每个执行时间大约创建一次作业对象[...]。该Cronjob是仅负责创建与其时间表匹配的工作，并且 Job则负责Pod的管理代表。

这意味着所有吊舱/容器故障应由作业控制器处理（即，调整jobTemplate）。

“重试”作业：

万一作业失败，您无需重新创建Cronjob。您只需要等待下一个时间表。

如果要在下一个计划之前运行新作业，可以使用Cronjob模板通过以下方式手动创建作业：

kubectl create job --from=cronjob/my-cronjob-name my-manually-job-name

您应该做什么：

如果您的容器无法持续下载图像，则可以使用以下选项：

显式设置backoffLimit并将其调整为更高的值。
对容器使用restartPolicy: OnFailure，以便Pod停留在节点上，并且仅容器会重新运行。
考虑使用imagePullPolicy: IfNotPresent。如果您不重新标记图像，则无需在每次作业开始时都强制重新拉动。

Answer 2

仅需扩展Eduardo Baitello的答案，我还要提及另外两个警告：

Eduardo提到了Cronjob Limitations，但并未扩展Too many missed start time (> 100)问题。为此，我发现唯一的解决方案是删除cronjob并重新创建它。您可以修补cronjob以降低其频率，从而使调度程序再次运行它。然后，您可以将其重新打回原来的状态，但这比较棘手。 kubectl describe cronjob CRONJOB_NAME应该将此事件列为其事件之一，并且通常会影响频繁的cronjob。
如果您有很多Cronjobs / Jobs，则可能会遇到1.14.7中已修复的此错误（#77465）。如果整个集群中有多个500个作业，则会发生这种情况。很难找到该日志，但是您可以在kube-scheduler日志中查询expected type *batchv1.JobList, got type *internalversion.List。

您可以使用以下命令为kube-scheduler打印日志：

kubectl -n kube-system logs -l component=kube-scheduler --tail 100

Kubernetes CronJob停止计划作业

2 个答案:

kubernetes作业如何处理故障

Cronjobs

您应该做什么：