富顺住房和城乡建设厅网站/线下推广都有什么方式
本章节将分享kubernetes中的job控制器和cronjob控制器，这是用于另外两种场景的pod控制器。
一、job控制器
对于Deployment、ReplicaSet、ReplicationController等类型的控制器而言，它希望pod保持预期数目、持久运行下去，除非用户明确删除，否则这些对象一直存在，它们针对的是耐久性任务，如web服务等。对于非耐久性任务，比如压缩文件，任务完成后，pod需要结束运行，不需要pod继续保持在系统中，这个时候就要用到Job。因此说Job是对Deployment、ReplicaSet等持久性控制器的补充。目前在实际工作中，这两种类型的控制器使用不多。
Job与其它控制器的细微差别：
Job定义方法与RC（RS）控制器类似，有细微差别，如下：
Job中的restartPolicy仅支持Never或OnFailure，这个很好理解，因为pod要运行到结束，而不是反复重新启动。
Job不需要选择器，其中的pod也不需要标签，系统在创建Job时会自动添加相关内容。当然用户也可以出于资源组织的目的添加标签，但这个与Job本身的实现没有关系。
Job新增加两个字段：.spec.completions、.spec.parallelism。
Job的重要参数：
- spec.backoffLimit指定在此Job在标记为失败之前重试的次数，默认为6次
- spec.completions标志Job结束需要成功运行的Pod个数，默认为1
- spec.parallelism标志并行运行的Pod的个数，默认为1
具体语法格式可以通过kubectl explain job.spec查看
根据.spec.completions和.spec.Parallelism的设置，可以将Job划分为以下几种pattern：
| Job类型 | 使用示例 | 行为 | completions | Parallelism |
|---|---|---|---|---|
| 一次性Job | 数据库迁移 | 创建一个Pod直至其成功运行结束 | 1 | 1 |
| 固定结束次数的Job | 处理工作队列的Pod | 依次创建一个Pod运行直至有competition个后成功结束 | 2+ | 1 |
| 固定结束次数的并行Job | 多个Pod同时处理工作队列 | 依次创建一个Pod运行直至有competition个后成功结束 | 2+ | 2+ |
| 并行Job | 多个Pod同时处理工作队列 | 创建一个或多个Pod直至有一个成功结束 | 1 | 2+ |
Job Controller：
Job Controller负责根据Job Spec创建Pod，并持续监控Pod的状态，直至其成功结束。如果失败，则根据restartPolicy（只支持OnFailure和Never，不支持Always）决定是否创建新的Pod再次重试任务。
示例：
1、1个completions+1个Parallelism
[root@k8s-m1 k8s-volumes]# cat job.yml
apiVersion: batch/v1
kind: Job
metadata:name: pi
spec:template:metadata:name: pispec:containers:- name: piimage: perlcommand: ["perl", "-Mbignum=bpi", "-wle", "print bpi(10)"]restartPolicy: Never
##作用就是打印π的前10位[root@k8s-m1 k8s-volumes]# kubectl apply -f job.yml
job.batch/pi created[root@k8s-m1 k8s-volumes]# kubectl get pod -w
NAME READY STATUS RESTARTS AGE
annotations-test 1/1 Running 0 42h
pi-wdgql 0/1 ContainerCreating 0 9s
pi-wdgql 0/1 Completed 0 94s[root@k8s-m1 k8s-volumes]# kubectl logs pi-wdgql
3.141592654
.2、多个completions+1个Parallelism
[root@k8s-m1 k8s-volumes]# cat job.yml
apiVersion: batch/v1
kind: Job
metadata:name: busybox
spec:completions: 3template:metadata:name: busyboxspec:containers:- name: busyboximage: busyboxcommand: ["echo", "hello world"]restartPolicy: Never[root@k8s-m1 k8s-volumes]# kubectl apply -f job.yml
job.batch/busybox created[root@k8s-m1 k8s-volumes]# kubectl get pod
NAME READY STATUS RESTARTS AGE
annotations-test 1/1 Running 0 42h
busybox-5ffpp 0/1 Completed 0 42s
busybox-65hl6 0/1 Completed 0 48s
busybox-cpd8m 0/1 Completed 0 24s
pi-wdgql 0/1 Completed 0 8m45s
其他两种模式请自行测试使用。
裸Pods：
所谓裸Pods是指直接用PodSpec来创建的Pod，即没有使用RC（RS）或者Deployment控制器管理的Pods。这些Pod在Node重启后不会自动重启，但Job则会创建新的Pod继续任务。所以，推荐使用Job来替代裸Pods，即便是应用只需要一个Pod。
二、cronjob控制器
类似于Linux的Crond服务的功能，CronJob用来执行定时性任务，或者周期性、重复性任务。注意CronJob启动的是kubernetes中的Job，不是ReplicaSet、DaemonSet等其它控制器类型。用途：
- 在给定时间点只运行一次
- 在给定时间点周期性地运行，如：数据库备份、发送邮件。
格式参数：
具体语法格式可以通过kubectl explain cronjob.spec查看
下面解释CronJob中的重要字段。
- schedule 指定什么时候运行 Job，其格式与 Linux cron 一致。这里 */1 * * * * 的含义是每一分钟运行一次。
- jobTemplate 定义 Job 的模板，格式与Job控制器的模板一致。
- spec.startingDeadlineSeconds：单位是秒，表示如果Job因为某种原因无法按调度准时启动，在spec.startingDeadlineSeconds时间段之内，CronJob仍然试图重新启动Job，如果在.spec.startingDeadlineSeconds时间之内没有启动成功，则不再试图重新启动。如果spec.startingDeadlineSeconds的值没有设置，则没有按时启动的任务不会被尝试重新启动。spec.startingDeadlineSeconds同时也影响到CronJob计算任务损失率。如果指定，那么CronJob计算有多少Job没有按时启动时是从当前时间向后推spec.startingDeadlineSeconds秒数，如果没有指定，那么是从当前时间向后推到最后一次成功调度的时间。无论那种算法，如果损失的按时任务超过一定个数，那么CronJob会报错并停止运行。
- spec.concurrencyPolicy：并发策略，字段可选，有三个可选项。
Allow：上一次Job没有完成，本次Job可以启动。
Forbid：上一次Job没有完成，本次Job不可以启动。
Replace：上一次Job没有完成，本次Job取而代之，用一个新的来替换。 - spec.suspend：true或者false，表示是否临时阻塞CronJob，它对已经开始执行的 Job 不起作用。默认值为 false。
- spec.successfulJobsHistoryLimit：保存成功历史Job的数量，默认３，如果为０则CronJob在Job成功后立即删除。
.spec.failedJobsHistoryLimit：保存失败历史Job的数量，默认１，如果为0则CronJob在Job失败后立即删除。
示例：
以下CronJob每分钟运行一次，打印出当前时间与hello消息。
apiVersion: batch/v1beta1
kind: CronJob
metadata:name: hello
spec:schedule: "*/1 * * * *"jobTemplate:spec:template:spec:containers:- name: helloimage: busyboxargs:- /bin/sh- -c- date; echo Hello WorldrestartPolicy: OnFailure#以上内容，schedule: "*/1 * * * *"与Linux Crond中定义相同，表示每分钟启动一次。#运行CronJob
[root@k8s-m1 k8s-volumes]# kubectl create -f cronjob.yml
cronjob.batch/hello created
#或者通过命令行方式：[root@k8s-m1 k8s-volumes]# kubectl run hello --schedule="*/1 * * * *" --restart=OnFailure --image=busybox -- /bin/sh -c "date; echo Hello World"
cronjob "hello" created
#查看CronJob状态：
[root@k8s-m1 k8s-volumes]# kubectl get cronjobs.batch
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
hello */1 * * * * False 0 <none> 31s- NAME：CronJob名称。
- SCHEDULE：基于时间的调度规则。
- SUSPEND：如果其值为True表示此CronJob暂时失效，不变成False之前不再创建新任务。对于已经创建的任务没有影响。
- ACTIVE：表示当前活动的任务数，0表示当前没有活动任务。1表示有一个活动任务。此值可能大于1，原因如下：
任务允许重复启动，如前一次启动后还没有退出，下一次已经启动。
允许延后启动，当CronJob Controller发现因为某种原因错误启动，并且任务允许延后启动，则会启动任务。 - LAST-SCHEDULE：表示最后一次调度时间是多久之前
从CronJob状态可以看出，其输出中并没有相关字段指示其所创建的JOB是否运行成功，运行如上命令查看JOB的详细信息： - AGE：该cronjob存在的时间
查看CronJob创建的Job：
[root@k8s-m1 k8s-volumes]# kubectl get jobs --watch
NAME COMPLETIONS DURATION AGE
hello-1687845000 1/1 20s 2m38s
hello-1687845060 1/1 19s 97s
hello-1687845120 1/1 5s 37s
- NAME：表示CronJob创建的Job名称，后边的数字由系统自动生成，保证不重复。
- COMPLETIONS ：表示历史执行的job数量和成功数量。
- DURATION ：表示pod的持续时间。
- AGE：表示该Job是多长时间之前执行的。
CronJob 中保存的任务其实是有上限的，spec.successfulJobsHistoryLimit 和 spec.failedJobsHistoryLimit 分别记录了能够保存的成功或者失败的任务上限，超过这个上限的任务都会被删除，默认情况下这两个属性分别为 spec.successfulJobsHistoryLimit=3 和 spec.failedJobsHistoryLimit=1。
CronJob创建Job，Job创建pod，通过下面的方法可以查看job对应的pod（名字的前面两节一样）：
[root@k8s-m1 k8s-volumes]# kubectl get jobs.batch
NAME COMPLETIONS DURATION AGE
hello-1687846440 1/1 19s 2m57s
hello-1687846500 1/1 5s 116s
hello-1687846560 1/1 20s 56s[root@k8s-m1 k8s-volumes]# kubectl get pods
NAME READY STATUS RESTARTS AGE
hello-1687846440-9v5kq 0/1 Completed 0 2m58s
hello-1687846500-h77rc 0/1 Completed 0 118s
hello-1687846560-w72jf 0/1 Completed 0 58s
[root@k8s-m1 k8s-volumes]# kubectl logs hello-1687846560-w72jf
Tue Jun 27 06:12:08 UTC 2023
Hello World
删除CronJob：
[root@k8s-m1 k8s-volumes]# kubectl delete cronjob hello
cronjob "hello" deleted
删除CronJob会使通过其创建的Job、pod一起被删除。
更多关于kubernetes的知识分享，请前往博客主页。编写过程中，难免出现差错，敬请指出