--
:
--
:
--
Job与CronJob
最后更新于:
Job 与 CronJob
接下来给大家介绍另外一类资源对象：Job，我们在日常的工作中经常都会遇到一些需要进行批量数据处理和分析的需求，当然也会有按时间来进行调度的工作。在我们的 Kubernetes 集群中为我们提供了 Job 和 CronJob 两种资源对象来应对我们的这种需求。
Job 负责处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束。而CronJob 则就是在 Job 上加上了时间调度。
Job和CronJob的应用场景：
1Job：机器学习
2CronJob：etcd/mysql backup
问题：Job可以运行在多个节点吗？
目录
[toc]
1、Job
==💘 实战：Job测试-2022.12.22（成功测试）==
- 实验环境
11、win10,vmwrokstation虚机；
22、k8s集群：3台centos7.6 1810虚机，2个master节点,1个node节点
3 k8s version：v1.20
4 CONTAINER-RUNTIME：containerd:v1.6.10
- 实验软件（无）
我们用 Job 这个资源对象来创建一个如下所示的任务，该任务负责计算 π 到小数点后 2000 位，并将结果打印出来，此计算大约需要 10 秒钟完成。对应的资源清单如下所示
1# job-pi.yaml
2apiVersion: batch/v1
3kind: Job
4metadata:
5 name: pi
6spec:
7 template:
8 spec:
9 containers:
10 - name: pi
11 image: perl:5.34.0
12 command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
13 restartPolicy: Never
14 backoffLimit: 4
我们可以看到 Job 中也是一个 Pod 模板，和之前的 Deployment、StatefulSet 之类的是一致的，只是 Pod 中的容器要求是一个任务，而不是一个常驻前台的进程了，因为需要退出。另外值得注意的是 Job 的 RestartPolicy 仅支
持 Never 和 OnFailure 两种，不支持 Always，我们知道 Job 就相当于来执行一个批处理任务，执行完就结束了，如果支持 Always 的话是不是就陷入了死循环了？
- 直接创建这个 Job 对象
1[root@master1 ~]#kubectl apply -f job-pi.yaml
2job.batch/pi created
3[root@master1 ~]#kubectl get job
4NAME COMPLETIONS DURATION AGE
5pi 0/1 4s 4s
6[root@master1 ~]#kubectl get po
7NAME READY STATUS RESTARTS AGE
8pi-rzsd8 0/1 ContainerCreating 0 7s
- Job 对象创建成功后，我们可以查看下对象的详细描述信息：
1[root@master1 ~]#kubectl describe job pi
2Name: pi
3Namespace: default
4Selector: controller-uid=90530e4b-1776-4221-ba69-516ecf4286ad #注意
5Labels: controller-uid=90530e4b-1776-4221-ba69-516ecf4286ad
6 job-name=pi
7Annotations: batch.kubernetes.io/job-tracking:
8Parallelism: 1
9Completions: 1
10Completion Mode: NonIndexed
11Start Time: Thu, 22 Dec 2022 21:53:08 +0800
12Completed At: Thu, 22 Dec 2022 21:54:02 +0800
13Duration: 54s
14Pods Statuses: 0 Active (0 Ready) / 1 Succeeded / 0 Failed
15Pod Template:
16 Labels: controller-uid=90530e4b-1776-4221-ba69-516ecf4286ad #注意
17 job-name=pi
18 Containers:
19 pi:
20 Image: perl:5.34.0
21 Port: <none>
22 Host Port: <none>
23 Command:
24 perl
25 -Mbignum=bpi
26 -wle
27 print bpi(2000)
28 Environment: <none>
29 Mounts: <none>
30 Volumes: <none>
31Events:
32 Type Reason Age From Message
33 ---- ------ ---- ---- -------
34 Normal SuccessfulCreate 2m16s job-controller Created pod: pi-rzsd8
35 Normal Completed 82s job-controller Job completed
可以看到，Job 对象在创建后，它的 Pod 模板，被自动加上了一个 controller-uid=< 一个随机字符串 > 这样的Label 标签，而这个 Job 对象本身，则被自动加上了这个 Label 对应的 Selector，从而保证了 Job 与它所管理的Pod 之间的匹配关系。而 Job 控制器之所以要使用这种携带了 UID 的 Label，就是为了避免不同 Job 对象所管理的Pod 发生重合。
- 我们可以看到隔一会儿后 Pod 变成了 Completed 状态，这是因为容器的任务执行完成正常退出了，我们可以查看对应的日志：
1[root@master1 ~]#kubectl get job
2NAME COMPLETIONS DURATION AGE
3pi 1/1 54s 70s
4[root@master1 ~]#kubectl get po
5NAME READY STATUS RESTARTS AGE
6pi-rzsd8 0/1 Completed 0 75s
7
8[root@master1 ~]#kubectl logs pi-rzsd8
93.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901
- 上面我们这里的 Job 任务对应的 Pod 在运行结束后，会变成 Completed 状态，但是如果执行任务的 Pod 因为某种原因一直没有结束怎么办呢？同样我们可以在 Job 对象中通过设置字段
spec.activeDeadlineSeconds来限制任务运行的最长时间，比如：
1spec:
2 activeDeadlineSeconds: 100
那么当我们的任务 Pod 运行超过了 100s 后，这个 Job 的所有 Pod 都会被终止，并且的终止原因会变成DeadlineExceeded。
测试activeDeadlineSeconds选项：
这里我们卸载刚才创建的资源，然后添加下activeDeadlineSeconds配置，再次观察效果：
卸载资源：
1[root@master1 ~]#kubectl delete -f job-pi.yaml
2job.batch "pi" deleted
然后添加下activeDeadlineSeconds配置：
1# job-pi.yaml
2apiVersion: batch/v1
3kind: Job
4metadata:
5 name: pi
6spec:
7 template:
8 spec:
9 containers:
10 - name: pi
11 image: perl:5.34.0
12 command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
13 restartPolicy: Never
14 #backoffLimit: 4 #先注视下这个配置
15 activeDeadlineSeconds: 5 #本来这个程序运行完成大概需要10s的时间，但这里activeDeadlineSeconds配置时间为5s，很明显任务会执行失败的哦。
重新部署，并观察现象：
1[root@master1 ~]#kubectl apply -f job-pi.yaml
2job.batch/pi created
3
4[root@master1 ~]#kubectl get job
5NAME COMPLETIONS DURATION AGE
6pi 0/1 10s 10s
7[root@master1 ~]#kubectl get po
8NAME READY STATUS RESTARTS AGE
9pi-pkp6w 0/1 ContainerCreating 0 4s
10
11
12[root@master1 ~]#kubectl get job,po
13NAME COMPLETIONS DURATION AGE
14job.batch/pi 0/1 17s 17s
15
16NAME READY STATUS RESTARTS AGE
17pod/pi-pkp6w 0/1 Terminating 0 17s
18
19
20[root@master1 ~]#kubectl get job,po
21NAME COMPLETIONS DURATION AGE
22job.batch/pi 0/1 37s 37s
23
24
25[root@master1 ~]#kubectl describe job pi
26Name: pi
27Namespace: default
28Selector: controller-uid=20d95fac-b232-4aa9-87a0-46f775c57981
29Labels: controller-uid=20d95fac-b232-4aa9-87a0-46f775c57981
30 job-name=pi
31Annotations: batch.kubernetes.io/job-tracking:
32Parallelism: 1
33Completions: 1
34Completion Mode: NonIndexed
35Start Time: Fri, 23 Dec 2022 06:44:44 +0800
36Active Deadline Seconds: 5s
37Pods Statuses: 0 Active (0 Ready) / 0 Succeeded / 1 Failed
38Pod Template:
39 Labels: controller-uid=20d95fac-b232-4aa9-87a0-46f775c57981
40 job-name=pi
41 Containers:
42 pi:
43 Image: perl:5.34.0
44 Port: <none>
45 Host Port: <none>
46 Command:
47 perl
48 -Mbignum=bpi
49 -wle
50 print bpi(2000)
51 Environment: <none>
52 Mounts: <none>
53 Volumes: <none>
54Events:
55 Type Reason Age From Message
56 ---- ------ ---- ---- -------
57 Warning FailedCreate 2m6s job-controller Error creating: Unauthorized
58 Normal SuccessfulCreate 2m6s job-controller Created pod: pi-pkp6w
59 Normal SuccessfulDelete 2m1s job-controller Deleted pod: pi-pkp6w
60 Warning DeadlineExceeded 2m1s job-controller Job was active longer than specified deadline #可以看到，刚创建的pod会被删除，同时任务执行失败，终止原因会变成DeadlineExceeded。(👉注意：这里失败的任务的pod最后是会被删除的)
🍓 测试restartPolicy选项
如果的任务执行失败了，会怎么处理呢，这个和定义的 restartPolicy 有关系，比如定义如下所示的 Job 任务，定义restartPolicy: Never 的重启策略：
- 配置资源清单：
1# job-failed-demo.yaml
2apiVersion: batch/v1
3kind: Job
4metadata:
5 name: job-failed-demo
6spec:
7 backoffLimit: 6 #所以要创建6次这个pod最终才会认为这个Job是失败的。
8 template:
9 spec:
10 containers:
11 - name: test-job
12 image: busybox
13 command: ["echo123", "test failed job!"] #当我们执行第一条任务的时候，失败，不重启，重新创建新的pod来跑任务。
14 restartPolicy: Never
- 直接创建上面的资源对象：
1[root@master1 ~]#kubectl apply -f job-failed-demo.yaml
2job.batch/job-failed-demo created
3
4[root@master1 ~]#kubectl get po
5NAME READY STATUS RESTARTS AGE
6job-failed-demo-2z8dw 0/1 StartError 0 6m30s
7job-failed-demo-96r5b 0/1 StartError 0 5m31s
8job-failed-demo-jwpbm 0/1 StartError 0 5m52s
9job-failed-demo-s97mw 0/1 StartError 0 5m12s
10job-failed-demo-t4hxg 0/1 StartError 0 5m49s
11job-failed-demo-tt9mb 0/1 StartError 0 6m10s
12job-failed-demo-xwrl4 0/1 StartError 0 6m48s
13
14[root@master1 ~]#kubectl get job
15NAME COMPLETIONS DURATION AGE
16job-failed-demo 0/1 7m3s 7m3s
17[root@master1 ~]#kubectl describe job
18Name: job-failed-demo
19Namespace: default
20Selector: controller-uid=658bbc99-11c3-4641-b79e-228d345be1c0
21Labels: controller-uid=658bbc99-11c3-4641-b79e-228d345be1c0
22 job-name=job-failed-demo
23Annotations: batch.kubernetes.io/job-tracking:
24Parallelism: 1
25Completions: 1
26Completion Mode: NonIndexed
27Start Time: Fri, 23 Dec 2022 07:07:28 +0800
28Pods Statuses: 0 Active (0 Ready) / 0 Succeeded / 7 Failed
29Pod Template:
30 Labels: controller-uid=658bbc99-11c3-4641-b79e-228d345be1c0
31 job-name=job-failed-demo
32 Containers:
33 test-job:
34 Image: busybox
35 Port: <none>
36 Host Port: <none>
37 Command:
38 echo123
39 test failed job!
40 Environment: <none>
41 Mounts: <none>
42 Volumes: <none>
43Events:
44 Type Reason Age From Message
45 ---- ------ ---- ---- -------
46 Normal SuccessfulCreate 7m5s job-controller Created pod: job-failed-demo-xwrl4
47 Normal SuccessfulCreate 6m47s job-controller Created pod: job-failed-demo-2z8dw
48 Normal SuccessfulCreate 6m27s job-controller Created pod: job-failed-demo-tt9mb
49 Normal SuccessfulCreate 6m9s job-controller Created pod: job-failed-demo-jwpbm
50 Normal SuccessfulCreate 6m6s job-controller Created pod: job-failed-demo-t4hxg
51 Normal SuccessfulCreate 5m48s job-controller Created pod: job-failed-demo-96r5b
52 Normal SuccessfulCreate 5m29s job-controller Created pod: job-failed-demo-s97mw
53 Warning BackoffLimitExceeded 5m26s job-controller Job has reached the specified backoff limit #但是这里任务失败最后确实不会删除pod的，为什么呢？？🤣
54[root@master1 ~]#
可以看到当我们设置成 Never 重启策略的时候，Job 任务执行失败后会不断创建新的 Pod，但是不会一直创建下去，会根据 spec.backoffLimit 参数进行限制，默认为 6，通过该字段可以定义重建 Pod 的次数。
需要注意的是：这里的backoffLimit 参数定义为6，但通过实际测试能够看到，这里的6次为在原来失败的1次基础上再尝试6次的，也就是总共会重建1+backoffLimit 次数的。
1[root@master1 ~]#kubectl explain job.spec
2 backoffLimit <integer>
3 Specifies the number of retries before marking this job failed. Defaults to
4 6
我们这里把spec.backoffLimit 参数设置为2时，也可以观察下现象，此时会看到pod被重建3次，也符合上面的结论。
1# job-failed-demo.yaml
2apiVersion: batch/v1
3kind: Job
4metadata:
5 name: job-failed-demo
6spec:
7 backoffLimit: 2 #配置次参数
8 template:
9 spec:
10 containers:
11 - name: test-job
12 image: busybox
13 command: ["echo123", "test failed job!"]
14 restartPolicy: Never
15
16[root@master1 ~]#kubectl apply -f job-failed-demo.yaml
17
18[root@master1 ~]#kubectl get po
19NAME READY STATUS RESTARTS AGE
20job-failed-demo-68nf2 0/1 StartError 0 2m47s
21job-failed-demo-hs6jg 0/1 StartError 0 3m9s
22job-failed-demo-r6cb8 0/1 StartError 0 3m5s
23[root@master1 ~]#kubectl get job
24NAME COMPLETIONS DURATION AGE
25job-failed-demo 0/1 3m12s 3m12s
26[root@master1 ~]#kubectl describe job job-failed-demo
27Name: job-failed-demo
28Namespace: default
29Selector: controller-uid=61696ae7-3d18-4304-9c13-d1f317c6b730
30Labels: controller-uid=61696ae7-3d18-4304-9c13-d1f317c6b730
31 job-name=job-failed-demo
32Annotations: batch.kubernetes.io/job-tracking:
33Parallelism: 1
34Completions: 1
35Completion Mode: NonIndexed
36Start Time: Fri, 23 Dec 2022 07:18:42 +0800
37Pods Statuses: 0 Active (0 Ready) / 0 Succeeded / 3 Failed
38Pod Template:
39 Labels: controller-uid=61696ae7-3d18-4304-9c13-d1f317c6b730
40 job-name=job-failed-demo
41 Containers:
42 test-job:
43 Image: busybox
44 Port: <none>
45 Host Port: <none>
46 Command:
47 echo123
48 test failed job!
49 Environment: <none>
50 Mounts: <none>
51 Volumes: <none>
52Events:
53 Type Reason Age From Message
54 ---- ------ ---- ---- -------
55 Normal SuccessfulCreate 3m14s job-controller Created pod: job-failed-demo-hs6jg
56 Normal SuccessfulCreate 3m10s job-controller Created pod: job-failed-demo-r6cb8
57 Normal SuccessfulCreate 2m52s job-controller Created pod: job-failed-demo-68nf2
58 Warning BackoffLimitExceeded 2m33s job-controller Job has reached the specified backoff limit
59[root@master1 ~]#
- 但是如果我们设置的 restartPolicy: OnFailure 重启策略，则当 Job 任务执行失败后不会创建新的 Pod 出来，只会不断重启 Pod，比如将上面的 Job 任务 restartPolicy 更改为 OnFailure 后查看 Pod：
1# job-failed-demo.yaml
2apiVersion: batch/v1
3kind: Job
4metadata:
5 name: job-failed-demo
6spec:
7 backoffLimit: 2
8 template:
9 spec:
10 containers:
11 - name: test-job
12 image: busybox
13 command: ["echo123", "test failed job!"]
14 restartPolicy: OnFailure
- 部署并测试：
1[root@master1 ~]#kubectl apply -f job-failed-demo.yaml
2job.batch/job-failed-demo created
3
4[root@master1 ~]#kubectl get po -w
5NAME READY STATUS RESTARTS AGE
6job-failed-demo-ldvd8 0/1 RunContainerError 0 (4s ago) 20s
7
8
9job-failed-demo-ldvd8 0/1 RunContainerError 1 (1s ago) 32s
10job-failed-demo-ldvd8 0/1 CrashLoopBackOff 1 (2s ago) 33s
11job-failed-demo-ldvd8 0/1 RunContainerError 2 (0s ago) 62s
12job-failed-demo-ldvd8 0/1 Terminating 2 (1s ago) 63s
13job-failed-demo-ldvd8 0/1 Terminating 2 63s
14job-failed-demo-ldvd8 0/1 Terminating 2 63s
15job-failed-demo-ldvd8 0/1 Terminating 2 64s
16job-failed-demo-ldvd8 0/1 Terminating 2 64s
17
18
19[root@master1 ~]#kubectl get po
20No resources found in default namespace.
21[root@master1 ~]#kubectl get job
22NAME COMPLETIONS DURATION AGE
23job-failed-demo 0/1 83s 83s
24[root@master1 ~]#kubectl describe job job-failed-demo
25Name: job-failed-demo
26Namespace: default
27Selector: controller-uid=c944db54-ea48-494d-84a7-31104f4f6195
28Labels: controller-uid=c944db54-ea48-494d-84a7-31104f4f6195
29 job-name=job-failed-demo
30Annotations: batch.kubernetes.io/job-tracking:
31Parallelism: 1
32Completions: 1
33Completion Mode: NonIndexed
34Start Time: Fri, 23 Dec 2022 07:27:40 +0800
35Pods Statuses: 0 Active (0 Ready) / 0 Succeeded / 1 Failed
36Pod Template:
37 Labels: controller-uid=c944db54-ea48-494d-84a7-31104f4f6195
38 job-name=job-failed-demo
39 Containers:
40 test-job:
41 Image: busybox
42 Port: <none>
43 Host Port: <none>
44 Command:
45 echo123
46 test failed job!
47 Environment: <none>
48 Mounts: <none>
49 Volumes: <none>
50Events:
51 Type Reason Age From Message
52 ---- ------ ---- ---- -------
53 Normal SuccessfulCreate 92s job-controller Created pod: job-failed-demo-ldvd8
54 Normal SuccessfulDelete 29s job-controller Deleted pod: job-failed-demo-ldvd8
55 Warning BackoffLimitExceeded 29s job-controller Job has reached the specified backoff limit #这里任务失败最后会删除pod的
56[root@master1 ~]#
🍓 测试spec.parallelism 参数
除此之外，我们还可以通过设置 spec.parallelism 参数来进行并行控制，该参数定义了一个 Job 在任意时间最多可以有多少个 Pod 同时运行。并行性请求（.spec.parallelism ）可以设置为任何非负整数，如果未设置，则默认为 1，如果设置为 0，则 Job 相当于启动之后便被暂停，直到此值被增加。spec.completions 参数可以定义 Job 至少要完成的 Pod 数目。
- 如下所示创建一个新的 Job 任务，设置允许并行数为 2，至少要完成的 Pod 数为 8：
1# job-para-demo.yaml
2apiVersion: batch/v1
3kind: Job
4metadata:
5 name: job-para-test
6spec:
7 parallelism: 2
8 completions: 8
9 template:
10 spec:
11 containers:
12 - name: test-job
13 image: busybox
14 command: ["echo", "test paralle job!"]
15 restartPolicy: Never
- 创建完成后查看任务状态：
1[root@master1 ~]#kubectl apply -f job-para-demo.yaml
2job.batch/job-para-test created
3
4[root@master1 ~]#kubectl get po -w
5NAME READY STATUS RESTARTS AGE
6job-para-test-r7jxq 0/1 Pending 0 0s
7job-para-test-r7jxq 0/1 Pending 0 0s
8job-para-test-np7gj 0/1 Pending 0 0s
9job-para-test-r7jxq 0/1 ContainerCreating 0 0s
10job-para-test-np7gj 0/1 Pending 0 0s
11job-para-test-np7gj 0/1 ContainerCreating 0 0s
12job-para-test-r7jxq 0/1 Completed 0 16s
13job-para-test-np7gj 0/1 Completed 0 16s
14job-para-test-r7jxq 0/1 Completed 0 18s
15job-para-test-np7gj 0/1 Completed 0 18s
16job-para-test-r9l7r 0/1 Pending 0 0s
17job-para-test-l2r2h 0/1 Pending 0 0s
18job-para-test-r9l7r 0/1 Pending 0 0s
19job-para-test-l2r2h 0/1 Pending 0 0s
20job-para-test-np7gj 0/1 Completed 0 19s
21job-para-test-r7jxq 0/1 Completed 0 19s
22job-para-test-r9l7r 0/1 ContainerCreating 0 0s
23job-para-test-l2r2h 0/1 ContainerCreating 0 0s
24job-para-test-l2r2h 0/1 Completed 0 16s
25job-para-test-r9l7r 0/1 Completed 0 17s
26job-para-test-l2r2h 0/1 Completed 0 18s
27job-para-test-r9l7r 0/1 Completed 0 19s
28job-para-test-b2wq8 0/1 Pending 0 0s
29job-para-test-b2wq8 0/1 Pending 0 0s
30job-para-test-nff6l 0/1 Pending 0 0s
31job-para-test-nff6l 0/1 Pending 0 0s
32job-para-test-b2wq8 0/1 ContainerCreating 0 0s
33job-para-test-r9l7r 0/1 Completed 0 19s
34job-para-test-l2r2h 0/1 Completed 0 19s
35job-para-test-nff6l 0/1 ContainerCreating 0 0s
36job-para-test-b2wq8 0/1 Completed 0 16s
37job-para-test-nff6l 0/1 Completed 0 17s
38job-para-test-nff6l 0/1 Completed 0 18s
39job-para-test-b2wq8 0/1 Completed 0 18s
40job-para-test-hzhdf 0/1 Pending 0 0s
41job-para-test-hzhdf 0/1 Pending 0 0s
42job-para-test-6nlmx 0/1 Pending 0 0s
43job-para-test-6nlmx 0/1 Pending 0 0s
44job-para-test-b2wq8 0/1 Completed 0 19s
45job-para-test-nff6l 0/1 Completed 0 19s
46job-para-test-hzhdf 0/1 ContainerCreating 0 0s
47job-para-test-6nlmx 0/1 ContainerCreating 0 0s
48job-para-test-6nlmx 0/1 Completed 0 2s
49job-para-test-6nlmx 0/1 Completed 0 4s
50job-para-test-6nlmx 0/1 Completed 0 5s
51job-para-test-hzhdf 0/1 Completed 0 16s
52job-para-test-hzhdf 0/1 Completed 0 18s
53job-para-test-hzhdf 0/1 Completed 0 19s
54
55
56[root@master1 ~]#kubectl get po
57NAME READY STATUS RESTARTS AGE
58job-para-test-6nlmx 0/1 Completed 0 16s
59job-para-test-b2wq8 0/1 Completed 0 35s
60job-para-test-hzhdf 0/1 Completed 0 16s
61job-para-test-l2r2h 0/1 Completed 0 54s
62job-para-test-nff6l 0/1 Completed 0 35s
63job-para-test-np7gj 0/1 Completed 0 73s
64job-para-test-r7jxq 0/1 Completed 0 73s
65job-para-test-r9l7r 0/1 Completed 0 54s
66[root@master1 ~]#kubectl get job
67NAME COMPLETIONS DURATION AGE
68job-para-test 8/8 76s 77s
可以看到一次可以有 2 个 Pod 同时运行，需要 8 个 Pod 执行成功，如果不是 8 个成功，那么会根据restartPolicy 的策略进行处理，可以认为是一种检查机制。
🍓 .spec.completionMode测试
此外带有确定完成计数的 Job，即 .spec.completions 不为 null 的 Job， 都可以在其.spec.completionMode 中设置完成模式：
NonIndexed（默认值） ：当成功完成的 Pod 个数达到 .spec.completions 所设值时认为 Job 已经完成。换言之，每个 Job 完成事件都是独立无关且同质的。要注意的是，当 .spec.completions 取值为 null 时，Job被默认处理为NonIndexed 模式。
Indexed：Job 的 Pod 会获得对应的完成索引，取值为 0 到 .spec.completions-1，该索引可以通过三种方式获取：
- Pod 的注解 batch.kubernetes.io/job-completion-index。
- 作为 Pod 主机名的一部分，遵循模式 $(job-name)-$(index)。当你同时使用带索引的 Job（IndexedJob）与服务（Service），Job 中的 Pod 可以通过 DNS 使用确切的主机名互相寻址。
- 对于容器化的任务，在环境变量 JOB_COMPLETION_INDEX 中可以获得。
当每个索引都对应一个成功完成的 Pod 时，Job 被认为是已完成的。
索引完成模式
下面我们将运行一个使用多个并行工作进程的 Kubernetes Job，每个 worker 都是在自己的 Pod 中运行的不同容器。Pod 具有控制平面自动设置的索引编号（index number）， 这些编号使得每个 Pod 能识别出要处理整个任务的哪个部分。
Pod 索引在注解 batch.kubernetes.io/job-completion-index 中呈现，具体表示为一个十进制值字符串。为了让容器化的任务进程获得此索引，我们可以使用 downward API 机制来获取注解的值。而且控制平面会自动设置 Downward API 在 JOB_COMPLETION_INDEX 环境变量中暴露索引。
- 我们这里创建一个如下所示的 Job 资源清单文件：
1# job-indexed.yaml
2apiVersion: batch/v1
3kind: Job
4metadata:
5 name: indexed-job
6spec:
7 completions: 5
8 parallelism: 3
9 completionMode: Indexed
10 template:
11 spec:
12 restartPolicy: Never
13 initContainers:
14 - name: "input"
15 image: "bash"
16 command:
17 - "bash"
18 - "-c"
19 - |
20 items=(foo bar baz qux xyz)
21 echo ${items[$JOB_COMPLETION_INDEX]} > /input/data.txt
22 volumeMounts:
23 - mountPath: /input
24 name: input
25 containers:
26 - name: "worker"
27 image: "busybox"
28 command:
29 - "rev"
30 - "/input/data.txt"
31 volumeMounts:
32 - mountPath: /input
33 name: input
34 volumes:
35 - name: input
36 emptyDir: {}
在该资源清单中我们设置了 completionMode: Indexed，表示这是一个 Indexed 完成模式的 Job 任务。这里我们还使用了 Job 控制器为所有容器设置的内置 JOB_COMPLETION_INDEX 环境变量。 Init 容器将索引映射到一个静态
值，并将其写入一个文件，该文件通过 emptyDir 卷 与运行 worker 的容器共享。
**rev （reverse）**命令用于将文件中的每行内容以字符为单位反序输出，即第一个字符最后输出，最后一个字符最先输出，以此类推。
- 直接创建该资源对象并验证：
1[root@master1 ~]#kubectl apply -f job-indexed.yaml
2job.batch/indexed-job created
3[root@master1 ~]#kubectl get job
4NAME COMPLETIONS DURATION AGE
5indexed-job 0/5 21s 21s
当你创建此 Job 时，控制平面会创建一系列 Pod，你指定的每个索引都会运行一个 Pod。.spec.parallelism 的值决定了一次可以运行多少个 Pod， 而 .spec.completions 决定了 Job 总共创建了多少个 Pod。
因为 .spec.parallelism 小于 .spec.completions， 所以控制平面在启动更多 Pod 之前，将等待第一批的某些Pod 完成。
1[root@master1 ~]#kubectl get po -w
2NAME READY STATUS RESTARTS AGE
3indexed-job-0-cfnjb 0/1 Pending 0 0s
4indexed-job-0-cfnjb 0/1 Pending 0 0s
5indexed-job-2-hgf5b 0/1 Pending 0 0s
6indexed-job-1-bzszz 0/1 Pending 0 0s
7indexed-job-2-hgf5b 0/1 Pending 0 0s
8indexed-job-1-bzszz 0/1 Pending 0 0s
9indexed-job-0-cfnjb 0/1 Init:0/1 0 0s
10indexed-job-2-hgf5b 0/1 Init:0/1 0 0s
11indexed-job-1-bzszz 0/1 Init:0/1 0 0s
12indexed-job-2-hgf5b 0/1 PodInitializing 0 1s
13indexed-job-0-cfnjb 0/1 PodInitializing 0 1s
14indexed-job-1-bzszz 0/1 PodInitializing 0 16s
15indexed-job-0-cfnjb 0/1 Completed 0 17s
16indexed-job-0-cfnjb 0/1 Completed 0 19s
17indexed-job-3-fmktp 0/1 Pending 0 0s
18indexed-job-3-fmktp 0/1 Pending 0 0s
19indexed-job-0-cfnjb 0/1 Completed 0 20s
20indexed-job-3-fmktp 0/1 Init:0/1 0 0s
21indexed-job-2-hgf5b 0/1 Completed 0 32s
22indexed-job-2-hgf5b 0/1 Completed 0 34s
23indexed-job-4-htzhm 0/1 Pending 0 0s
24indexed-job-4-htzhm 0/1 Pending 0 0s
25indexed-job-2-hgf5b 0/1 Completed 0 35s
26indexed-job-4-htzhm 0/1 Init:0/1 0 0s
27indexed-job-3-fmktp 0/1 PodInitializing 0 16s
28indexed-job-3-fmktp 0/1 Completed 0 17s
29indexed-job-3-fmktp 0/1 Completed 0 19s
30indexed-job-3-fmktp 0/1 Completed 0 20s
31indexed-job-1-bzszz 0/1 Completed 0 47s
32indexed-job-4-htzhm 0/1 PodInitializing 0 12s
33indexed-job-1-bzszz 0/1 Completed 0 49s
34indexed-job-1-bzszz 0/1 Completed 0 50s
35indexed-job-4-htzhm 0/1 Completed 0 28s
36indexed-job-4-htzhm 0/1 Completed 0 30s
37indexed-job-4-htzhm 0/1 Completed 0 31s
38
39[root@master1 ~]#kubectl get po
40NAME READY STATUS RESTARTS AGE
41indexed-job-0-cfnjb 0/1 Completed 0 84s
42indexed-job-1-bzszz 0/1 Completed 0 84s
43indexed-job-2-hgf5b 0/1 Completed 0 84s
44indexed-job-3-fmktp 0/1 Completed 0 64s
45indexed-job-4-htzhm 0/1 Completed 0 49s
46
47[root@master1 ~]#kubectl get job
48NAME COMPLETIONS DURATION AGE
49indexed-job 5/5 66s 97s
创建 Job 后，稍等片刻，就能检查进度：
1[root@master1 ~]#kubectl describe job indexed-job
2Name: indexed-job
3Namespace: default
4Selector: controller-uid=be1f722a-a889-42e5-bc25-e242c8d3cc63
5Labels: controller-uid=be1f722a-a889-42e5-bc25-e242c8d3cc63
6 job-name=indexed-job
7Annotations: batch.kubernetes.io/job-tracking:
8Parallelism: 3
9Completions: 5
10Completion Mode: Indexed
11Start Time: Fri, 23 Dec 2022 21:18:30 +0800
12Completed At: Fri, 23 Dec 2022 21:19:36 +0800
13Duration: 66s
14Pods Statuses: 0 Active (0 Ready) / 5 Succeeded / 0 Failed
15Completed Indexes: 0-4
16Pod Template:
17 Labels: controller-uid=be1f722a-a889-42e5-bc25-e242c8d3cc63
18 job-name=indexed-job
19 Init Containers:
20 input:
21 Image: bash
22 Port: <none>
23 Host Port: <none>
24 Command:
25 bash
26 -c
27 items=(foo bar baz qux xyz)
28 echo ${items[$JOB_COMPLETION_INDEX]} > /input/data.txt
29
30 Environment: <none>
31 Mounts:
32 /input from input (rw)
33 Containers:
34 worker:
35 Image: busybox
36 Port: <none>
37 Host Port: <none>
38 Command:
39 rev
40 /input/data.txt
41 Environment: <none>
42 Mounts:
43 /input from input (rw)
44 Volumes:
45 input:
46 Type: EmptyDir (a temporary directory that shares a pod's lifetime)
47 Medium:
48 SizeLimit: <unset>
49Events:
50 Type Reason Age From Message
51 ---- ------ ---- ---- -------
52 Normal SuccessfulCreate 116s job-controller Created pod: indexed-job-0-cfnjb
53 Normal SuccessfulCreate 116s job-controller Created pod: indexed-job-1-bzszz
54 Normal SuccessfulCreate 116s job-controller Created pod: indexed-job-2-hgf5b
55 Normal SuccessfulCreate 96s job-controller Created pod: indexed-job-3-fmktp
56 Normal SuccessfulCreate 81s job-controller Created pod: indexed-job-4-htzhm
57 Normal Completed 50s job-controller Job completed
这里我们使用的每个索引的自定义值运行 Job，我们可以检查其中一个 Pod 的输出：
1[root@master1 ~]#kubectl logs indexed-job-3-fmktp
2xuq
我们在初始化容器中执行了如下所示的命令：
1 items=(foo bar baz qux xyz)
2 echo ${items[$JOB_COMPLETION_INDEX]} > /input/data.txt
当 JOB_COMPLETION_INDEX=3 的时候表示我们将 items[3] 的 qux 值写入到了 /input/data.txt 文件中，然后通过 volume 共享，在主容器中我们通过 rev 命令将其反转，所以输出结果就位 xuq 了。
上面我们这个示例中每个 Pod 只做一小部分工作（反转一个字符串）。 在实际工作中肯定比这复杂，比如你可能会创建一个基于场景数据制作 60 秒视频任务的 Job，此视频渲染 Job 中的每个工作项都将渲染该视频剪辑的特定帧，索引完成模
式意味着 Job 中的每个 Pod 都知道通过从剪辑开始计算帧数，来确定渲染和发布哪一帧，这样就可以大大提高工作任务的效率。
2、CronJob
CronJob 其实就是在 Job 的基础上加上了时间调度，我们可以在给定的时间点运行一个任务，也可以周期性地在给定时间点运行。这个实际上和我们 Linux 中的 crontab 就非常类似了。
一个 CronJob 对象其实就对应中 crontab 文件中的一行，它根据配置的时间格式周期性地运行一个 Job，格式和 crontab 也是一样的。
crontab 的格式为：分 时 日 月 星期 要运行的命令 。
1# ┌───────────── 分钟 (0 - 59)
2# │ ┌───────────── 小时 (0 - 23)
3# │ │ ┌───────────── 月的某天 (1 - 31)
4# │ │ │ ┌───────────── 月份 (1 - 12)
5# │ │ │ │ ┌───────────── 周的某天 (0 - 6)（周日到周一；在某些系统上，7 也是星期日）
6# │ │ │ │ │ 或者是 sun，mon，tue，web，thu，fri，sat
7# │ │ │ │ │
8# │ │ │ │ │
9# * * * * *
- 第1列分钟 0～59
- 第2列小时 0～23
- 第3列日 1～31
- 第4列月 1～12
- 第5列星期 0～7（0和7表示星期天）
- 第6列要运行的命令
所有 CronJob 的 schedule 时间都是基于 kube-controller-manager 的时区，如果你的控制平面在 Pod 中运行了 kube-controller-manager， 那么为该容器所设置的时区将会决定 CronJob 的控制器所使用的时区。官方并不支持设置如 CRON_TZ 或者 TZ 等变量，这两个变量是用于解析和计算下一个 Job 创建时间所使用的内部库中一个实现细节，不建议在生产集群中使用它。
但是如果在 kube-controller-manager 中启用了 CronJobTimeZone 这个 Feature Gates，那么我们就可以为CronJob 指定一个时区（如果你没有启用该特性门控，或者你使用的是不支持试验性时区功能的 Kubernetes 版本，集群中所有 CronJob 的时区都是未指定的）。启用该特性后，你可以将 spec.timeZone 设置为有效时区名称。
==💘 实战：CronJob测试-2022.12.22（成功测试）==
- 实验环境
11、win10,vmwrokstation虚机；
22、k8s集群：3台centos7.6 1810虚机，2个master节点,1个node节点
3 k8s version：v1.20
4 CONTAINER-RUNTIME：containerd:v1.6.10
实验软件（无）
老样子，首先我们来看下
CronJob的字段：
1[root@master1 ~]#kubectl explain CronJob.spec
2FIELDS:
3 concurrencyPolicy <string>
4 Specifies how to treat concurrent executions of a Job. Valid values are: -
5 "Allow" (default): allows CronJobs to run concurrently; - "Forbid": forbids
6 concurrent runs, skipping next run if previous run hasn't finished yet; -
7 "Replace": cancels currently running job and replaces it with a new one
8#单词说明：concurrentcy 并发，并行 executions执行册数，运行次数
9
10 failedJobsHistoryLimit <integer>
11 The number of failed finished jobs to retain. Value must be non-negative
12 integer. Defaults to 1.
13#单词说明：non-negative非负的，正的
14
15 jobTemplate <Object> -required->
16 Specifies the job that will be created when executing a CronJob.
17
18 schedule <string> -required->
19 The schedule in Cron format, see https://en.wikipedia.org/wiki/Cron.
20
21 startingDeadlineSeconds <integer>
22 Optional deadline in seconds for starting the job if it misses scheduled
23 time for any reason. Missed jobs executions will be counted as failed ones.
24
25 successfulJobsHistoryLimit <integer>
26 The number of successful finished jobs to retain. Value must be
27 non-negative integer. Defaults to 3.
28
29 suspend <boolean>
30 This flag tells the controller to suspend subsequent executions, it does
31 not apply to already started executions. Defaults to false.
32#单词说明：suspend v.悬挂；暂停，中止 subsequent 分布式
33[root@master1 ~]#
- 现在，我们用
CronJob来管理我们上面的Job任务，定义如下所示的资源清单：
1# cronjob-demo.yaml
2apiVersion: batch/v1
3kind: CronJob
4metadata:
5 name: cronjob-demo
6spec:
7 schedule: "*/1 * * * *"
8 jobTemplate:
9 spec:
10 template:
11 spec:
12 restartPolicy: OnFailure
13 containers:
14 - name: hello
15 image: busybox
16 args:
17 - "bin/sh"
18 - "-c"
19 - "for i in 9 8 7 6 5 4 3 2 1; do echo $i; done"
这里的 Kind 变成了 CronJob 了，要注意的是 **.spec.schedule** 字段是必须填写的，用来指定任务运行的周期，格式就和 crontab 一样。另外一个字段是 .spec.jobTemplate, 用来指定需要运行的任务，格式当然和 Job 是一致的。还有一些值得我们关注的字段 .spec.successfulJobsHistoryLimit(默认为3) 和 .spec.failedJobsHistoryLimit(默认为1)，表示历史限制，是可选的字段，指定可以保留多少完成和失败的 Job。然而，当运行一个 CronJob 时，Job 可以很快就堆积很多，所以一般推荐设置这两个字段的值，如果设置限制的值为 0，那么相关类型的 Job 完成后将不会被保留。
- 我们直接新建上面的资源对象：
1[root@master1 ~]#kubectl apply -f cronjob-demo.yaml
2cronjob.batch/cronjob-demo created
- 然后可以查看对应的 Cronjob 资源对象：
1[root@master1 ~]#kubectl get cronjobs
2NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
3cronjob-demo */1 * * * * False 1 14s 16s
- 稍微等一会儿查看可以发现多了几个 Job 资源对象，这个就是因为上面我们设置的 CronJob 资源对象，每1分钟执行一个新的 Job：
1[root@master1 ~]#kubectl get po,job
2NAME READY STATUS RESTARTS AGE
3pod/cronjob-demo-27291254--1-m54nz 0/1 Completed 0 79s
4pod/cronjob-demo-27291255--1-m8l8v 0/1 ContainerCreating 0 19s
5
6NAME COMPLETIONS DURATION AGE
7job.batch/cronjob-demo-27291254 1/1 22s 79s
8job.batch/cronjob-demo-27291255 0/1 19s 19s
9[root@master1 ~]#
10
11再过一段时间查看：
12[root@master1 ~]#kubectl get po,job
13NAME READY STATUS RESTARTS AGE
14pod/cronjob-demo-27291254--1-m54nz 0/1 Completed 0 2m10s
15pod/cronjob-demo-27291255--1-m8l8v 0/1 Completed 0 70s
16pod/cronjob-demo-27291256--1-d449d 0/1 ContainerCreating 0 10s
17
18NAME COMPLETIONS DURATION AGE
19job.batch/cronjob-demo-27291254 1/1 22s 2m10s
20job.batch/cronjob-demo-27291255 1/1 21s 70s
21job.batch/cronjob-demo-27291256 0/1 10s 10s
22[root@master1 ~]#
- 这个就是 CronJob 的基本用法，一旦不再需要 CronJob，我们可以使用 kubectl 命令删除它：
1[root@master1 ~]#kubectl delete cronjob cronjob-demo
2cronjob "cronjob-demo" deleted
不过需要注意的是这将会终止正在创建的 Job，但是运行中的 Job 将不会被终止，不会删除 Job 或 它们的 Pod。
测试结束。😘
关于我
我的博客主旨：
- 排版美观，语言精炼；
- 文档即手册，步骤明细，拒绝埋坑，提供源码；
- 本人实战文档都是亲测成功的，各位小伙伴在实际操作过程中如有什么疑问，可随时联系本人帮您解决问题，让我们一起进步！
🍀 微信二维码
x2675263825 （舍得）， qq：2675263825。
🍀 微信公众号
《云原生架构师实战》
🍀 语雀
https://www.yuque.com/xyy-onlyone
https://www.yuque.com/xyy-onlyone/exkgza?# 《语雀博客》
🍀 博客
🍀 csdn
https://blog.csdn.net/weixin_39246554?spm=1010.2135.3001.5421
🍀 知乎
https://www.zhihu.com/people/foryouone
最后
好了，关于本次就到这里了，感谢大家阅读，最后祝大家生活快乐，每天都过的有意义哦，我们下期见！
1
📡
推荐使用微信支付
推荐使用支付宝
