一. Job
- Job 任务,Job内部实际也可以看为部署pod,实现任务,
apiVersion: batch/v1
kind: Job
metadata:
name: job-test-04
spec:
completions: 5 #默认1, 当前job任务执行成功几次才算完成(前一次必须结束才会下一次)
parallelism: 3 #默认1, 任务的并发数(例如当前任务一次执行3个)
template:
spec:
containers:
- name: pi
image: busybox #job类型的pod,不要用阻塞式的(如Deployment才应该是阻塞式的)
command: ["/bin/sh","-c","ping -c 10 baidu.com"] #指定任务命令
restartPolicy: Never #Job情况下,不支持Always
backoffLimit: 4 #任务失败重试次数
activeDeadlineSeconds: 600 #整个Job的存活时间,超出就自动杀死(多次执行一共的时间)
ttlSecondsAfterFinished: 10 #运行完成后等待指定实际自己删除
- 查看job情况:“kubectl get job”
二. CronJob
- CronJob定时任务,可以这样理解,通过CronJob定时任务定时创建Job, 然后通过Job启动pod实现定时任务的运行
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *" #定时表达式:分,时,日,月,周
jobTemplate:
# kind: Job
spec: ## 以下是Job的写法
template:
spec:
containers:
- name: hello
image: busybox
args:
- /bin/sh
- -c
- date; echo Hello from the Kubernetes cluster
restartPolicy: OnFailure
- 注意点: 一个CronJob在时间计划中的每次执行时刻,都创建大约一个Job对象。这里用到了大约,是因为在少数情况下会创建两个Job对象,或者不创建Job对象。尽管K8S尽最大的可能性避免这种情况的出现,但是并不能完全杜绝此现象的发生。因此,Job程序必须是幂等的。1min执行一次
- concurrencyPolicy: 并发策略
- Allow: 允许(默认值)
- Forbid: 禁止,前个任务没执行完,要并发下一个的话,下一个会被跳过
- Replace: 替换,新任务替换当前运行的任务
- startingDeadlineSeconds: 启动的超时时间
推荐与concurrencyPolicy配合使用, concurrencyPolicy设置为Allow,startingDeadlineSeconds设置一个较大的时间,进而保证至少有一个CronJob任务运行
- failedJobsHistoryLimit:记录失败数的上限 Defaults to1
- successfulJobsHistoryLimit:记录成功任务的上限Defaults to3
- suspend: 暂停定时任务,对已经执行了的任务,不会生效;Defaults to false
- startingDeadlineSeconds:表示如果Job因为某种原因无法按调度准时启动,在spec.startingDeadlineSeconds时间段之内,CronJob仍然试图重新启动Job,如果在.spec.startingDeadlineSeconds时间之内没有启动成功,则不再试图重新启动。如果spec.startingDeadlineSeconds的值没有设置,则没有按时启动的任务不会被尝试重新启动。