121 lines
5.5 KiB
Markdown
121 lines
5.5 KiB
Markdown
<h1><center>kubernetes工作负载资源CronJob</center></h1>
|
||
|
||
|
||
|
||
------
|
||
|
||
## 一：CronJob
|
||
|
||
CronJob创建基于时隔重复调度的Jobs
|
||
|
||
一个 CronJob 对象就像 *crontab* 文件中的一行。 它用Cron格式进行编写， 并周期性地在给定的调度时间执行 Job
|
||
|
||
注意：
|
||
|
||
所有 **CronJob** 的 `schedule:` 时间都是基于kube-controller-manager. 的时区
|
||
|
||
如果你的控制平面在 Pod 或是裸容器中运行了 kube-controller-manager， 那么为该容器所设置的时区将会决定 Cron Job 的控制器所使用的时区
|
||
|
||
Kubernetes 项目官方并不支持设置如 `CRON_TZ` 或者 `TZ` 等变量。 `CRON_TZ` 或者 `TZ` 是用于解析和计算下一个 Job 创建时间所使用的内部库中一个实现细节。 不建议在生产集群中使用它
|
||
|
||
#### 1.创建CronJob
|
||
|
||
```shell
|
||
[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
|
||
|
||
```hello
|
||
[root@master xingdian]# kubectl create -f CronJob.yaml
|
||
cronjob.batch/hello created
|
||
```
|
||
|
||
#### 3.获取其状态
|
||
|
||
```shell
|
||
[root@master xingdian]# kubectl get cronjob
|
||
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
|
||
hello * * * * * False 3 18s 2m34s
|
||
```
|
||
|
||
CronJob 还没有调度或执行任何任务，大约需要一分钟任务才能创建好：
|
||
|
||
```shell
|
||
[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 个活跃的任务意味着任务执行完毕或者执行失败
|
||
|
||
```shell
|
||
[root@master xingdian]# kubectl get cronjob
|
||
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
|
||
hello * * * * * False 3 18s 2m34s
|
||
```
|
||
|
||
#### 4.时间语法表
|
||
|
||
```shell
|
||
# ┌───────────── 分钟 (0 - 59)
|
||
# │ ┌───────────── 小时 (0 - 23)
|
||
# │ │ ┌───────────── 月的某天 (1 - 31)
|
||
# │ │ │ ┌───────────── 月份 (1 - 12)
|
||
# │ │ │ │ ┌───────────── 周的某天 (0 - 6)（周日到周一；在某些系统上，7 也是星期日）
|
||
# │ │ │ │ │ 或者是 sun，mon，tue，web，thu，fri，sat
|
||
# │ │ │ │ │
|
||
# │ │ │ │ │
|
||
# * * * * *
|
||
```
|
||
|
||
```shell
|
||
输入 描述 相当于
|
||
@yearly (or @annually) 每年 1 月 1 日的午夜运行一次 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：允许如上所示的并发
|
||
|
||
Forbid：CronJob 不允许并发任务执行；如果新任务的执行时间到了老任务没有执行完，CronJob 忽略新任务的执行
|
||
|
||
Replace：如果新任务的执行时间到了而老任务没有执行完，CronJob 会用新任务替换当前正在运行的任务
|
||
|
||
`spec.successfulJobsHistoryLimit`和`spec.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:00` 到 `10:21:00`）终止运行， 则 Job 仍将从 `10:22:00` 开始。 造成这种情况的原因是控制器现在检查在最近 200 秒（即 3 个错过的调度）中发生了多少次错过的 Job 调度，而不是从现在为止的最后一个调度时间开始
|
||
|
||
|
||
|