kubernetes-x/kubernetes-MD/kubernetes工作负载资源CronJob.md

5.5 KiB
Raw Blame History

kubernetes工作负载资源CronJob

著作:行癫 <盗版必究>


CronJob

CronJob创建基于时隔重复调度的Jobs

一个 CronJob 对象就像 crontab 文件中的一行。 它用Cron格式进行编写 并周期性地在给定的调度时间执行 Job

注意:

所有 CronJobschedule: 时间都是基于kube-controller-manager. 的时区

如果你的控制平面在 Pod 或是裸容器中运行了 kube-controller-manager 那么为该容器所设置的时区将会决定 Cron Job 的控制器所使用的时区

Kubernetes 项目官方并不支持设置如 CRON_TZ 或者 TZ 等变量。 CRON_TZ 或者 TZ 是用于解析和计算下一个 Job 创建时间所使用的内部库中一个实现细节。 不建议在生产集群中使用它

1.创建CronJob

[root@master xingdian]# cat CronJob.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: 10.0.0.230/xingdian/nginx:v2
            imagePullPolicy: IfNotPresent
          restartPolicy: OnFailure

2.运行CronJob

[root@master xingdian]# kubectl create -f CronJob.yaml
cronjob.batch/hello created

3.获取其状态

[root@master xingdian]# kubectl get cronjob
NAME    SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE
hello   * * * * *   False     3        18s             2m34s

CronJob 还没有调度或执行任何任务,大约需要一分钟任务才能创建好:

[root@master xingdian]# kubectl get jobs --watch
NAME             COMPLETIONS   DURATION   AGE
hello-27526413   0/1           3m32s      3m32s
hello-27526414   0/1           2m32s      2m32s
hello-27526415   0/1           92s        92s
hello-27526416   0/1           32s        32s

你应该能看到 hello CronJob 在 LAST SCHEDULE 声明的时间点成功的调度了一次任务。 有 0 个活跃的任务意味着任务执行完毕或者执行失败

[root@master xingdian]# kubectl get cronjob
NAME    SCHEDULE    SUSPEND   ACTIVE   LAST SCHEDULE   AGE
hello   * * * * *   False     3        18s             2m34s

4.时间语法表

# ┌───────────── 分钟 (0 - 59)
# │ ┌───────────── 小时 (0 - 23)
# │ │ ┌───────────── 月的某天 (1 - 31)
# │ │ │ ┌───────────── 月份 (1 - 12)
# │ │ │ │ ┌───────────── 周的某天 (0 - 6)周日到周一在某些系统上7 也是星期日)
# │ │ │ │ │                          或者是 sunmontuewebthufrisat
# │ │ │ │ │
# │ │ │ │ │
# * * * * *
输入	描述	相当于
@yearly (or @annually)	每年 11 日的午夜运行一次	0 0 1 1 *
@monthly	每月第一天的午夜运行一次	0 0 1 * *
@weekly	每周的周日午夜运行一次	0 0 * * 0
@daily (or @midnight)	每天午夜运行一次	0 0 * * *
@hourly	每小时的开始一次	0 * * * *

例如,下面这行指出必须在每个星期五的午夜以及每个月 13 号的午夜开始任务0 0 13 * 5

计划任务时间表:https://crontab.guru/

5.参数解释

在 CronJob 对象上设置spec.concurrencyPolicy字段可让您控制此行为。它具有三个可能的值

Allow允许如上所示的并发

ForbidCronJob 不允许并发任务执行如果新任务的执行时间到了老任务没有执行完CronJob 忽略新任务的执行

Replace如果新任务的执行时间到了而老任务没有执行完CronJob 会用新任务替换当前正在运行的任务

spec.successfulJobsHistoryLimitspec.failedJobsHistoryLimit这两个值分别控制 Kubernetes 保留成功和失败作业历史的时间。它们默认为三个成功的作业和一个失败的作业,默认设置为3和1。限制设置为 0 代表相应类型的任务完成后不会保留。

.spec.startingDeadlineSeconds 域是可选的。 它表示任务如果由于某种原因错过了调度时间开始该任务的截止时间的秒数。过了截止时间CronJob 就不会开始任务。 不满足这种最后期限的任务会被统计为失败任务。如果该域没有声明,那任务就没有最后期限,如果.spec.startingDeadlineSeconds字段被设置(非空)CronJob 控制器会计算从预期创建 Job 到当前时间的时间差。 如果时间差大于该限制,则跳过此次执行,如果将其设置为 200,则 Job 控制器允许在实际调度之后最多 200 秒内创建 Job如果 startingDeadlineSeconds 的设置值低于 10 秒钟CronJob 可能无法被调度。 这是因为 CronJob 控制器每 10 秒钟执行一次检查。

例如:假设将 CronJob 设置为从 08:30:00 开始每隔一分钟创建一个新的 Job 并将其 startingDeadlineSeconds 字段设置为 200 秒。 如果 CronJob 控制器恰好在与上一个示例相同的时间段(08:29:0010:21:00)终止运行, 则 Job 仍将从 10:22:00 开始。 造成这种情况的原因是控制器现在检查在最近 200 秒(即 3 个错过的调度)中发生了多少次错过的 Job 调度,而不是从现在为止的最后一个调度时间开始