标签：CronJob name kubernetes demo Job job Pod spec
Kubernetes的主要任务是保证Pod中的应用长久稳定的运行，但是我们有时候也需要一些只需要运行一次，执行完就退出了的"短时"任务，这时候使用Deployment等这类控制器就无法满足我们的需求，Kubernetes就诞生了Job Controller，专门用来处理这类需求。
1、Job
1.1、基本操作
Job负责处理仅执行一次的任务，它保证批处理的任务的一个或多个成功结束，我们可以通过kubectl explain job来查看具体语法，如下：
[root@master ~]# kubectl explain job
KIND: Job
VERSION: batch/v1
DESCRIPTION:
Job represents the configuration of a single job.
FIELDS:
apiVersion <string>
APIVersion defines the versioned schema of this representation of an
object. Servers should convert recognized schemas to the latest internal
value, and may reject unrecognized values. More info:
https://git.k8s.io/community/contributors/devel/api-conventions.md#resources
kind <string>
Kind is a string value representing the REST resource this object
represents. Servers may infer this from the endpoint the client submits
requests to. Cannot be updated. In CamelCase. More info:
https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds
metadata <Object>
Standard object's metadata. More info:
https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata
spec <Object>
Specification of the desired behavior of a job. More info:
https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status
status <Object>
Current status of a job. More info:
https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status从上面可以看到跟我们定义Deployment，Pod的语法是差不多的，下面我们定义一个Job的YAML文件：
job-demo.yaml
apiVersion: batch/v1
kind: Job
metadata:
name: job-demo
namespace: default
spec:
template:
metadata:
name: job-demo
spec:
containers:
- name: test-job
image: busybox
imagePullPolicy: IfNotPresent
command:
- "/bin/sh"
- "-c"
args:
- "for i in $(seq 10); do echo $i; done"
restartPolicy: Never
backoffLimit: 4从上面的YAML文件我们可以看到Job的spec里就是我们熟悉的Pod模板。我们执行kubectl apply -f job-demo.yaml，查看运行信息：
[root@master job]# kubectl get job
NAME COMPLETIONS DURATION AGE
job-demo 1/1 5s 7s
[root@master job]# kubectl describe job job-demo
Name: job-demo
Namespace: default
Selector: controller-uid=5000fea1-8af7-4199-b482-082b7e94f6fd
Labels: controller-uid=5000fea1-8af7-4199-b482-082b7e94f6fd
job-name=job-demo
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"batch/v1","kind":"Job","metadata":{"annotations":{},"name":"job-demo","namespace":"default"},"spec":{"backoffLimit":4,"temp...
Parallelism: 1
Completions: 1
Start Time: Wed, 23 Oct 2019 15:55:19 +0800
Completed At: Wed, 23 Oct 2019 15:55:24 +0800
Duration: 5s
Pods Statuses: 0 Running / 1 Succeeded / 0 Failed
Pod Template:
Labels: controller-uid=5000fea1-8af7-4199-b482-082b7e94f6fd
job-name=job-demo
Containers:
test-job:
Image: busybox
Port: <none>
Host Port: <none>
Command:
/bin/sh
-c
Args:
for i in $(seq 10); do echo $i; done
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal SuccessfulCreate 15s job-controller Created pod: job-demo-f9hmn从上面可以看到在Pod里自动生成了一个controller-uid的label，然后在Job的selector也会自动加上这个label，这就建立Job和它管理的Pod之间的对应关系。
接下来我们查看这个Pod的状态，如下：
[root@master job]# kubectl get pod
NAME READY STATUS RESTARTS AGE
job-demo-f9hmn 0/1 Completed 0 2m35s我们可以看到执行结束后，STATUS变成了Completed状态，而且RESTARTS为0（表示为重启）。我们也可以看一下这个Pod的日志，如下：
[root@master job]# kubectl logs job-demo-f9hmn
1
2
3
4
5
6
7
8
9
10我们可以看到这个Pod只运行了一次。
那么如果这个任务执行失败了呢？比如我们将上面的YAML文件中的args参数随便改一个非Linux命令，如下：
......
args:
- "xxxxxx"
......然后我们查看Pod的状态：
[root@master job]# kubectl get pod
NAME READY STATUS RESTARTS AGE
job-demo-2ccjq 0/1 Error 0 11s
job-demo-hwss6 0/1 ContainerCreating 0 3s我们看到这个Job任务没有执行成功，我们定义了restartPolicy=Never，这时候Job Controller就会创建一个新的Pod。我们在Job的YAML文件里定义了backoffLimit=4，这表明重试次数只有4次，默认是6次，4次重试都还未成功，则这个Job则失败：
[root@master job]# kubectl get pod
NAME READY STATUS RESTARTS AGE
job-demo-2ccjq 0/1 Error 0 3m21s
job-demo-2kdpc 0/1 Error 0 2m43s
job-demo-7q62j 0/1 Error 0 3m3s
job-demo-hwss6 0/1 Error 0 3m13s
You have new mail in /var/spool/mail/root
[root@master job]# kubectl get job
NAME COMPLETIONS DURATION AGE
job-demo 0/1 5m49s 5m49s
You have new mail in /var/spool/mail/root如果我们定义restartPolicy=OnFailure，如果作业失败，Job Controller就不会在创建新的Pod，但是会不断重启这个Pod。如下，我们把Job的YAML文件中的restartPolicy改成restartPolicy=OnFailure，测试如下：
[root@master job]# kubectl get pod
NAME READY STATUS RESTARTS AGE
job-demo-cbmft 0/1 Error 3 69s我们可以看到RESTARTS变为了1，表示重启了3次。
还有一种情况，如果这个Job一直不肯结束怎么办呢？比如我们将上面的YAML文件做如下修改：
apiVersion: batch/v1
kind: Job
metadata:
name: job-demo
namespace: default
spec:
template:
metadata:
name: job-demo
spec:
containers:
- name: test-job
image: busybox
imagePullPolicy: IfNotPresent
command:
- "/bin/sh"
- "-c"
args:
- "sleep 3600"
restartPolicy: OnFailure
backoffLimit: 4然后执行kubectl apply -f job-demo.yaml。我们可以发现这个Pod不会结束直到3600秒后，这时候如果我们加一个参数activeDeadlineSeconds，如下：
spec:
......
restartPolicy: OnFailure
backoffLimit: 4
activeDeadlineSeconds: 100这个参数的作用是如果这个Pod运行时间超过100s，这个Pod将被终止。
1.2、并行控制
在Job对象中，负责控制并行的参数为：
-
completions：定义Job至少要完成的Pod数目，既Job的最小完成数；
- parallelism：定义一个Job在任意时间最多可以启动多少个Pod;
我们定义下面一个Job的YAML文件：
apiVersion: batch/v1
kind: Job
metadata:
name: job-demo
namespace: default
spec:
parallelism: 2
completions: 4
template:
metadata:
name: job-demo
spec:
containers:
- name: test-job
image: busybox
imagePullPolicy: IfNotPresent
command:
- "/bin/sh"
- "-c"
args:
- "for i in $(seq 10); do echo $i; done"
restartPolicy: OnFailure
backoffLimit: 4
activeDeadlineSeconds: 100parallelism: 2 和 completions: 4表示要完成4个pod，每次可以同时运行两个Pod，我们创建这个Job。
[root@master job]# kubectl apply -f job-demo.yaml
job.batch/job-demo created
[root@master job]# kubectl get pod
NAME READY STATUS RESTARTS AGE
job-demo-kcm4c 0/1 ContainerCreating 0 1s
job-demo-kdrxl 0/1 Completed 0 4s
job-demo-r4k49 0/1 ContainerCreating 0 2s
job-demo-w9c49 0/1 Completed 0 4s可以看到两个运行结束，另外两个才开始。
1.3、原理总结
从上面可以知道，Job Controller实际控制的就是Pod，它在创建的时候会在Job和Pod里自动生成随机字符串的label，然后将它们进行绑定。
Job Controller在实际的调谐操作是根据实际在running状态的Pod数，还有已经退出的Pod数以及parallelism和completions的参数值共同计算出在Job周期内应该创建或者删除多少Pod，然后调用kube-api来执行这类操作。
所以Job Controller实际上是控制的Pod的并行度以及总共要完成的任务数这两个重要的参数。
1.4、使用场景
1.4.1、外部管理器+Job模板
用法：把Job的YAML文件定义为一个模板，然后用外部工具来控制这个模板生成Job。
比如我们定义如下YAML：
apiVersion: batch/v1
kind: Job
metadata:
name: process-item-$ITEM
labels:
jobgroup: jobexample
spec:
template:
metadata:
name: jobexample
labels:
jobgroup: jobexample
spec:
containers:
- name: c
image: busybox
command: ["sh", "-c", "echo Processing item $ITEM && sleep 5"]
restartPolicy: Never我们在这个YAML文件里设定了一个$ITEM的变量，然后我们使用外部脚本来通过这个YAML文件生成Job，如下：
$ mkdir ./jobs
$ for i in apple banana cherry
do
cat job-tmpl.yaml | sed "s/\$ITEM/$i/" > ./jobs/job-$i.yaml
done然后就会生成三个Job文件，这时候就可以通过kubectl apply -f .来执行这些Job。
1.4.2、固定任务数的并行Job
在这种场景下，我们只关注是否有我们定义的指定数目的任务成功退出，并不会去关心并行度是多少。
比如：
apiVersion: batch/v1
kind: Job
metadata:
name: job-wq-1
spec:
completions: 8
parallelism: 2
template:
metadata:
name: job-wq-1
spec:
containers:
- name: c
image: myrepo/job-wq-1
env:
- name: BROKER_URL
value: amqp://guest:guest@rabbitmq-service:5672
- name: QUEUE
value: job1
restartPolicy: OnFailure上面的文件会以并发度为2的方式创建8个Pod，然后每个Pod各自去处理任务，我们最终只关心是否有8个Pod启动并且退出，只要这个目标达成，我们就认为这个Job成功执行。
1.4.3、设置并行度，不设置固定值
这种情况就必须自己决定什么时候启动Pod，什么时候执行完成，由于没有限制任务的总数，所以不仅需要一个工作队列来决定任务的分发，还需要能够判定工作队列是否为空，也就是任务是否完成。
如下：
apiVersion: batch/v1
kind: Job
metadata:
name: job-wq-2
spec:
parallelism: 2
template:
metadata:
name: job-wq-2
spec:
containers:
- name: c
image: gcr.io/myproject/job-wq-2
env:
- name: BROKER_URL
value: amqp://guest:guest@rabbitmq-service:5672
- name: QUEUE
value: job2
restartPolicy: OnFailure由于任务数不确定，所以每个Pod必须能够知道，自己什么时候可以退出。
2、CronJob
CronJob其实就在Job的基础上加了时间调度，类似于用Deployment管理Pod一样。它和我们Linux上的Crontab差不多。
比如：
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
command:
- "/bin/sh"
- "-c"
args:
- "for i in $(seq 10); do echo $i; done"
restartPolicy: OnFailure我们可以看到spec里其实就是一个Job Template。另外其schedule就是一个便准的Cron格式，
分钟 小时 日 月 星期
* * * * *我们创建上面的YAML文件。查看其结果：
[root@master job]# kubectl apply -f cronjob-demo.yaml
cronjob.batch/hello created
[root@master job]# kubectl get cronjobs.batch
NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
hello */1 * * * * False 0 <none> 5s需要注意的是，由于cron的特殊性，有时候会存在由于上一个定时任务还没有执行完成，新的定时任务又开始了的情况，我们可以通过定义spec.concurrencyPolicy字段来定义规则，比如：
-
concurrencyPolicy=Allow：表示这些Job可以同时存在
-
concurrencyPolicy=Firbid：表示不会创建新的Job，也就是这个定时任务被跳过
- concurrencyPolicy=Replace：表示产生的新Job会替代旧的Job
如果某一个Job创建失败，那么这次创建就会被标记为miss，当在指定的时间窗口内，Miss的数达到100，那么CronJob就会停止再创建这个Job。这个时间窗口可以通过spec.startingDeadlineSeconds来指定。
完
标签：CronJob,name,kubernetes,demo,Job,job,Pod,spec 来源： https://blog.51cto.com/15080014/2654529
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。