CronJob

Autopilot Standard

---

CronJob 在 Google Kubernetes Engine (GKE) 1.21 及更高版本中正式发布 (GA)。本文档介绍如何在 GKE 中运行 CronJob。CronJob 是 Kubernetes 的一项内置功能。如需了解详情，请参阅有关 CronJob 的 Kubernetes 文档。

概览

CronJob 按重复时间表创建 Kubernetes 作业。借助 CronJob，您可以自动执行一些常规任务，例如备份、创建报告、发送电子邮件或清理任务。

CronJob 的创建、管理、扩缩和删除方式与 Job 相同。创建的具体 Job 对象数取决于多个因素。如需了解详情，请参阅 CronJob 限制。

如需详细了解 Job，请参阅运行 Job。

准备工作

在开始之前，请确保您已执行以下任务：

• 启用 Google Kubernetes Engine API。
启用 Google Kubernetes Engine API
• 如果您要使用 Google Cloud CLI 执行此任务，请安装并初始化 gcloud CLI。 如果您之前安装了 gcloud CLI，请运行 gcloud components update 以获取最新版本。
  注意：对于现有 gcloud CLI 安装，请务必设置 compute/region 和 compute/zone 属性。通过设置默认位置，您可以避免 gcloud CLI 中出现以下错误：One of [--zone, --region] must be supplied: Please specify location。

创建 CronJob

您可以使用清单文件创建 CronJob。例如，以下 YAML 清单每分钟输出一次当前时间和字符串，同时保留 CronJob 参数的默认值：

# cronjob.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  concurrencyPolicy: Allow
  startingDeadlineSeconds: 100
  suspend: false
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo "Hello, World!"
          restartPolicy: OnFailure

注意：如果您的集群运行 1.21 之前的 GKE 版本，请在 apiVersion 字段中指定 batch/v1beta1。

如需创建此 CronJob，请将 YAML 清单保存到文件中，并将其应用于集群：

kubectl apply -f PATH_TO_FILE

将 PATH_TO_FILE 替换为 YAML 清单的路径。

配置 CronJob

创建 CronJob 时，您可以指定以下参数：

• CronJob 的运行时间
• CronJob 的作用
• CronJob 启动的截止时间
• CronJob 是否允许并发作业
• 新作业是否被暂停
• CronJob 在其历史记录中保存的执行次数

指定 CronJob 的运行时间

spec.schedule 字段使用 Unix 标准 crontab 格式定义 CronJob 的运行时间和频率。所有 CronJob 时间均采用世界协调时间 (UTC)。其中有 5 个字段，以空格分隔。这些字段代表以下内容：

1. 分钟（介于 0 到 59 之间）
2. 小时（介于 0 到 23 之间）
3. 一个月中的某天（介于 1 到 31 之间）
4. 月份（介于 1 到 12 之间）
5. 周几（介于 0 到 6 之间，从星期日开始）

您可以在任意 spec.schedule 字段中使用以下特殊字符：

• ? 是与单个字符匹配的通配符值。
• * 是与零个或多个字符匹配的通配符值。
• / 可用于为字段指定间隔。例如，如果第一个字段（“分钟”字段）的值为 */5，则表示“每 5 分钟”。如果第五个字段（“周几”字段）设置为 0/5，则表示“每五个周日”。

指定 CronJob 的运行内容

spec.jobTemplate 描述了 CronJob 的作用，包括容器映像、容器执行的命令以及 CronJob 的重启政策。如需详细了解要添加到 spec.jobTemplate 中的内容，请参阅 Kubernetes CronJob 文档。

指定截止时限

可选的 startingDeadlineSeconds 字段指示在 CronJob 由于某种原因错过了计划时间的情况下为了启动而耗用的最长时间（以秒为单位）。错过的 CronJob 会被视作失败。

如需指定截止时限，请将 startingDeadlineSeconds 值添加到清单文件的 CronJob 的 spec 字段中。例如，以下清单指定 CronJob 在 100 秒内启动：

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  startingDeadlineSeconds: 100
  jobTemplate:
    spec:
    ...

注意：如果您为 startingDeadlineSeconds 字段指定空值，则 CronJob 永远不会超时。这可能会导致同一个 CronJob 同时运行多次。您可以通过指定并发政策来避免这种情况。

指定并发政策

可选的 spec.concurrencyPolicy 字段指定如何处理 CronJob 控制器创建的作业的并发执行。如果您不设置值，则系统默认允许执行多个并发作业。

concurrencyPolicy 接受以下值：

值	含义
Allow	允许执行并发作业。这是默认设置。
Forbid	并发作业被禁止，在之前的作业完成或超时之前，新作业无法启动。
Replace	并发作业被禁止，旧作业被取消，取而代之的是新作业。

暂停后续执行

如果将可选的 spec.suspend 字段设置为 true，将阻止新作业运行，但允许当前执行项完成。

指定历史限制

CronJob 每次运行时都会创建一个 Pod。查看 CronJob 历史记录中介绍了如何查看 CronJob 的最近执行项的终止状态以及个别 Pod 的日志。

您可以通过指定 spec.successfulJobsHistoryLimit 和 spec.failedJobsHistoryLimit 的值来配置保存的成功和失败的 CronJob 执行项数量。默认情况下，successfulJobsHistoryLimit 设置为 3，failedJobsHistoryLimit 设置为 1。

例如，以下清单指示 GKE 保存最多 5 次成功的 CronJob 执行以及最多 10 次失败的 CronJob 执行：

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  startingDeadlineSeconds: 100
  successfulJobsHistoryLimit: 5
  failedJobsHistoryLimit: 10
  jobTemplate:
    spec:
    ...

您可以通过将相应的值设置为 0 来停用成功或失败的 CronJob 执行历史记录的保留。停用历史记录保留可能会使调试失败变得更加困难。例如，以下清单指示 GKE 仅保存失败的 CronJob 执行：

kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  startingDeadlineSeconds: 100
  successfulJobsHistoryLimit: 0
  failedJobsHistoryLimit: 10
  jobTemplate:
    spec:
    ...

检查 CronJob

如需查看 CronJob 的配置，请使用 kubectl describe：

kubectl describe cronjob CRONJOB_NAME

将 CRONJOB_NAME 替换为要检查的 CronJob 的名称。

查看 CronJob 历史记录

CloJob 在 Pod 中运行。默认情况下，Kubernetes 会保留已终止的 Pod 的日志，这些 Pod 代表 CronJob 的最后三个成功运行项以及最近的一个失败作业。您可以通过更改 CronJob 历史记录限制来更改或停用这些默认值。

要查看 CronJob 的历史记录，请先列出所有 Pod。已完成的 CronJob 的状态为 Completed，失败的作业状态为 RunContainerError、CrashLoopBackOff 或其他表示失败的状态。

注意：您可能会看到超出预期的条目。CronJob 历史记录会定期进行垃圾回收。例如，在下面的输出中，显示了 hello CronJob 的四个实例。

NAME                                READY   STATUS              RESTARTS   AGE
hello-1556555640-9bc5r              0/1     Completed           0          3m6s
hello-1556555700-cm6wk              0/1     Completed           0          2m6s
hello-1556555760-62wf5              0/1     Completed           0          66s
hello-1556555820-rl8kl              0/1     Completed           0          5s
hello-failed-1556555820-wrvt2       0/1     RunContainerError   1          5s

您可以通过修改创建 CronJob 中的示例清单来故意使某个作业失败。将 spec.containers 中的 args 字段更改为无效命令或不存在的路径，并将 metadata.name 值更改为表示您正在测试失败操作的值。

如需查看特定 CronJob 的日志，请运行以下命令：

kubectl logs POD_NAME

将 POD_NAME 替换为您要检查的 Pod 的名称。

输出内容类似如下：

container_linux.go:247: starting container process caused
"exec: \"/in/sh\": stat /in/sh: no such file or directory"

删除 CronJob

要删除 CronJob，请运行以下命令：

kubectl delete cronjob CRONJOB_NAME

删除 CronJob 时，Kubernetes 垃圾收集器会删除关联的作业，并且会阻止任何新作业启动。

后续步骤

• 阅读有关 CronJob 的 Kubernetes 文档。
• 了解如何运行一次性作业。