我们在日常的工作中经常会遇到一些需要进行批量数据处理和分析的需求,当然也会有按时间进行调度的工作,在kubernetes集群中为我们提供了job和Cronjob两种资源对象来应对这种需求。
目录
2、successfulJobsHistoryLimit 和failedJobsHistoryLimit
3、startingDeadlineSeconds:任务延迟开始的最后期限
k8s的Job和Cronjob
主要任务包含两种:
- Job负责批处理任务,即仅执行一次的任务,它保证批处理的一个或者多个Pod成功结束。
- Cronjob是基于job的基础上添加了时间调度。
一、job:
1、机制
- Job 会创建一个或者多个 Pod,并将继续重试 Pod 的执行,直到指定数量的(.spec.completions) Pod 成功终止。
- 随着 Pod 成功结束(.status.phase=Succeeded),Job 跟踪记录成功完成的 Pod 个数。当数量达到指定的成功个数阈值时,任务(即 Job)结束。
- 删除 Job 的操作会清除所创建的全部 Pod。
- 挂起 Job 的操作会删除 Job 的所有活跃 Pod,直到 Job 被再次恢复执行。
2、资源清单详解
- Job 的.spec 中只有.spec.template 是必需的字段
- Job中Pod的RestartPolicy(重启策略)只能设置为Never或者OnFailure之一。
- .spec.template.spec.restartPolicy = "OnFailure":容器失败后会不断重启,直到成功(退出码为0)
- .spec.template.spec.restartPolicy = "Never":容器不会重启,Pod的状态转为Failed
- Job的并行执行(.spec.parallelism和.spec.completions):官网
- Pod 回退失效策略(.spec.backoffLimit):官网
- Pod失效策略(.spec.podFailurePolicy):官网
- Job终止与清理(.spec.activeDeadlineSeconds):官网
- 已完成Job的TTL机制(.spec.ttlSecondsAfterFinished):官网
- 挂起Job(.spec.suspend):官网
apiVersion: batch/v1
kind: Job
metadata:
labels:
job-name: echo
name: job-test
namespace: default
spec:
suspend: true # 1.21+
activeDeadlineSeconds: 20 #Job的超时时间,一旦一个Job运行的时间超出该限制,则Job失败,所有运行中的Pod会被结束并删除。该配置指定的值必须是个正整数。不指定则不会超时
ttlSecondsAfterFinished: 20 # Job在执行结束之后(状态为completed或Failed)自动清理。设置为0表示执行结束立即删除,不设置则不会清除,需要开启TTLAfterFinished特性
backoffLimit: 4 # 如果任务执行失败,失败多少次后不再执行,默认为6,回退重试时间将会按指数增长 (从 10 秒、20 秒到 40 秒)最多至 6 分钟
completions: 1 # 有多少个Pod执行成功,认为任务是成功的,不设置默认和parallelism数值一样。如果completions和parallelism都不设置,默认值为1.
parallelism: 1 # 并行执行任务的数量,如果parallelism数值大于未完成任务数,只会创建未完成的数量;比如completions是4,并发是3,第一次会创建3个Pod执行任务,第二次只会创建一个Pod执行任务
template:
spec:
containers:
- command:
- echo
- Hello, Job
image: busybox
imagePullPolicy: Always
name: echo
resources: {}
restartPolicy: Never
3、使用job
1、创建一个job
[root@k8s-master-1 job-cronjob]# vim myjob.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: myjob
spec:
template:
metadata:
name: myjob
spec:
containers:
- name: hello
image: busybox:1.28.4
imagePullPolicy: IfNotPresent
command: ["echo","Hello k8s job"]
restartPolicy: Never
[root@k8s-master-1 job-cronjob]# kubectl apply -f myjob.yaml
job.batch/myjob created
[root@k8s-master-1 job-cronjob]# kubectl get job
NAME COMPLETIONS DURATION AGE
myjob 1/1 1s 24s
completions为 1/1 表示成功运行了这个job
[root@k8s-master-1 job-cronjob]# kubectl get pod
NAME READY STATUS RESTARTS AGE
myjob-4htdb 0/1 Completed 0 7s
看到 状态为Completed表示这个job已经运行完成
kubectl logs 命令查看这个 pod的日志
[root@k8s-master-1 job-cronjob]# kubectl logs myjob-4htdb
Hello k8s job
2、Job的执行失败
我们把command参数 改成错误的来测试
command: ["asc","Hello k8s job"]
由于我们的restartPolicy重启策略是不重启Never,我们改成重启:OnFailure,创建job,可以看到 这个容器一直在重启。
[root@k8s-master-1 job-cronjob]# kubectl get pod
NAME READY STATUS RESTARTS AGE
myjob-sdp7j 0/1 CrashLoopBackOff 4 2m54s
因为Pod的失败回退策略backoffLimit,默认值是6次,重启6次之后还是失败的话,就会删除这个容器,如下:状态为Terminating
[root@k8s-master-1 job-cronjob]# kubectl get pod
NAME READY STATUS RESTARTS AGE
myjob-sdp7j 0/1 Terminating 6 6m
3、并行执行job,添加如下参数
spec:
backoffLimit: 4
completions: 6
parallelism: 2
[root@k8s-master-1 job-cronjob]# kubectl get job
NAME COMPLETIONS DURATION AGE
myjob 4/6 3s 3s
[root@k8s-master-1 job-cronjob]#
[root@k8s-master-1 job-cronjob]#
[root@k8s-master-1 job-cronjob]# kubectl get pod
NAME READY STATUS RESTARTS AGE
myjob-fdknr 0/1 Completed 0 8s
myjob-l6gqs 0/1 Completed 0 5s
myjob-tcszq 0/1 Completed 0 6s
myjob-tw4kt 0/1 Completed 0 8s
myjob-z9g88 0/1 Completed 0 6s
myjob-zf94t 0/1 Completed 0 5s
二、Cronjob:定时任务
- Cronjob就是在Job的基础上加上了时间调度,我们可以:在给定的时间点运行一个任务,也可以周期性地在给定的时间点运行。
- 一个cronjob对象其实就对应cronjob文件中的一行,它根据配置的时间格式周期性地运行一个job,格式和cronjob也是一样的。
1、CronJob yaml资源清单
apiVersion: batch/v1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
successfulJobsHistoryLimit: 1
failedJobsHistoryLimit: 1
startingDeadlineSeconds: 60 ##CronJob 控制器将测量从预期创建作业到现在之间的时间。如果差异高于该限制,它将跳过此执行。 例如,如果设置为200,则它允许在实际计划后最多 200 秒内创建作业。
jobTemplate:
spec:
#ttlSecondsAfterFinished: 30
template:
spec:
containers:
- name: hello
image: busybox:1.28
imagePullPolicy: IfNotPresent
command: ["/bin/sh", "-c", " echo "," 123"]
restartPolicy: OnFailure
1、schedule
Cron 时间表语法:
# ┌───────────── 分钟 (0 - 59)
# │ ┌───────────── 小时 (0 - 23)
# │ │ ┌───────────── 月的某天 (1 - 31)
# │ │ │ ┌───────────── 月份 (1 - 12)
# │ │ │ │ ┌───────────── 周的某天 (0 - 6)(周日到周一;在某些系统上,7 也是星期日)
# │ │ │ │ │ 或者是 sun,mon,tue,web,thu,fri,sat
# * * * * *
例如
1、0 0 13 * 5 表示此任务必须在每个星期五的午夜以及每个月的 13 日的午夜开始
2、*:表示匹配该域的任意值,假如在Minutes域中使用"*",则表示每分钟都会触发事件
3、/:表示起始时间开始触发,然后每隔固定时间触发一次,例如在Minutes域设置为5/20,则意味着
第一次触发在第5分钟时,接下来每20分钟触发一次,将在第25分钟,第45分钟等时刻分别触发。
2、successfulJobsHistoryLimit 和failedJobsHistoryLimit
.spec.successfulJobsHistoryLimit 和.spec.failedJobsHistoryLimit字段是可选的。 这两个字段指定应保留多少已完成和失败的任务。 默认设置分别为 3 和 1。将限制设置为0 代表相应类型的任务完成后不会保留。
3、startingDeadlineSeconds:任务延迟开始的最后期限
.spec.startingDeadlineSeconds 字段是可选的。 它表示任务如果由于某种原因错过了调度时间,开始该任务的截止时间的秒数,过了截止时间,CronJob 就不会开始该任务的实例(未来的任务仍在调度之中)。
4、jobTemplate:任务模板
.spec.jobTemplate为 CronJob 创建的 Job 定义模板,它是必需的。它和 Job 的语法完全一样, 只不过它是嵌套的,
5、concurrencyPolicy:并发调度策略
.spec.concurrencyPolicy 也是可选的。它声明了 CronJob 创建的任务执行时发生重叠如何处理。 spec 仅能声明下列规则中的一种:
- Allow(默认):CronJob 允许并发任务执行。
- Forbid: CronJob 不允许并发任务执行;如果新任务的执行时间到了而老任务没有执行完,CronJob 会忽略新任务的执行。
- Replace:如果新任务的执行时间到了而老任务没有执行完,CronJob 会用新任务替换当前正在运行的任务。
6、ttlSecondsAfterFinished
假如jobTemplate添加了ttlSecondsAfterFinished,这个时候successfulJobsHistoryLimit和failedJobsHistoryLimit就会失效。例如ttlSecondsAfterFinished设置成30,这样不管这次的job是成功还是失败,在30秒后会照样清除
2、使用Cronjob
如上job使用,在其基础上,使用Cronjob
1、定时执行job,创建Cronjob
apiVersion: batch/v2alpha1
kind: CronJob
metadata:
name: mycronjob
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox:1.28.4
imagePullPolicy: IfNotPresent
command: ["echo","Hello k8s job"]
restartPolicy: OnFailure
[root@k8s-master-1 job-cronjob]# kubectl apply -f myCronjob.yaml
cronjob.batch/mycronjob created
可以看到 每隔1分钟,就会创建一个job
[root@k8s-master-1 job-cronjob]# kubectl get jobs
NAME COMPLETIONS DURATION AGE
mycronjob-1686385860 1/1 1s 3m4s
mycronjob-1686385920 1/1 2s 2m4s
mycronjob-1686385980 1/1 2s 64s
[root@k8s-master-1 job-cronjob]# kubectl delete -f myCronjob.yaml
cronjob.batch "mycronjob" deleted