Deployment、StatefulSet和DaemonSet这三个编排概念编排的对象主要都是在线业务（Long Running Task，这些应用一旦运行起来，除非出错或者停止，它的容器进程会一直保持在Running状态）。
但是对于离线业务（Batch Job，计算业务）在计算完成后就直接退出了，如果依然使用Deployment来管理，就会发现Pod会在计算结束后退出，然后被Deployment Controller不断重启。
在Kubernetes v1.4版本之后，设计出来一个用来描述离线业务的API对象：Job。
举个Job的栗子
apiVersion: batch/v1 kind: Job metadata: name: pi spec: template: spec: containers: - name: pi image: resouer/ubuntu-bc #安装了ba明了的Ubuntu镜像 command: ["sh", "-c", "echo 'scale=10000; 4*a(1)' | bc -l "] #bc命令是Linux里的计算器，； -l表示使用标准数学课； a(1)调用arctangent函数，scale指定小数点后的位数 restartPolicy: Never backoffLimit: 4
创建这个Pod
$ kubectl create -f job.yaml $ kubectl describe jobs/pi Name: pi Namespace: default Selector: controller-uid=c2db599a-2c9d-11e6-b324-0209dc45a495 Labels: controller-uid=c2db599a-2c9d-11e6-b324-0209dc45a495 job-name=pi Annotations: <none> Parallelism: 1 Completions: 1 .. Pods Statuses: 0 Running / 1 Succeeded / 0 Failed Pod Template: Labels: controller-uid=c2db599a-2c9d-11e6-b324-0209dc45a495 job-name=pi Containers: ... Volumes: <none> Events: FirstSeen LastSeen Count From SubobjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 1m 1m 1 {job-controller } Normal SuccessfulCreate Created pod: pi-rq5rl
可以看大这个Job对象在创建后，它的Pod模板被自动加上了一个Labels, controller-uid=<一个随机的字符串>。而Job对象本身，则被自动加上了这个Label对应的Selector，从而保证了Job与它所管理的Pod之间的匹配关系。
Job Controller之所以要使用这种携带了UID的Label，就是为了避免不同Job对象管理的Pod重合
### 接下来可以看到这个Job创建的Pod进入了Running状态，这意味着它正在计算Pi的值 $ kubectl get pods NAME READY STATUS RESTARTS AGE pi-rq5rl 1/1 Running 0 10s ###计算结束后，Pod会进入Completed状态，这也是需要在Pod模板中定义restartPolicy=Never的原因：离线计算的Pod永远不应该被重启 $ kubectl get pods NAME READY STATUS RESTARTS AGE pi-rq5rl 0/1 Completed 0 4m
### 通过查看log可以看到计算的值
$ kubectl logs pi-rq5rl
3.141592653589793238462643383279...
那如果这个离线作业失败了怎么办？因为这个例子中定义了restartPolicy=Never，那离线作业失败后Job Controller就会不断地尝试创建一个新Pod
Job对象的spec.backoffLimit字段限制尝试的次数，在例子中定义为4，默认值为6。Job Controller重新创建Pod的间隔是呈倍数增加的，即下一次重新创建Pod的动作会分别发生在10s,20s,40s……
那如果定义的restartPolicy=OnFailure呢？离线作业失败后，Job Controller就不会去尝试创建新的Pod，但是它会不断尝试重启Pod里的容器。
那如果这个Pod一直不肯结束呢？spec.activeDeadlineSeconds字段可以设置最长运行时间
spec: backoffLimit: 5 activeDeadlineSeconds: 100 # 运行超过100s，这个Job的所有Pod都会被终止
Job Controller 对并行作业的控制方法
在Job对象中，负责并行控制的参数有两个：
spec.parallelism：定义一个Job在任意时间最多可以启动多少个Pod同时运行
spec.completions：定义Job至少要玩的Pod的数目
再举个栗子
apiVersion: batch/v1 kind: Job metadata: name: pi spec: parallelism: 2 completions: 4 template: spec: containers: - name: pi image: resouer/ubuntu-bc command: ["sh", "-c", "echo 'scale=5000; 4*a(1)' | bc -l "] restartPolicy: Never backoffLimit: 4
指定了最大并行数是2，最小完成数是4
### 创建Job对象 $ kubectl create -f job.yaml ### Job维护两个字段，DESIRED即最小完成数 $ kubectl get job NAME DESIRED SUCCESSFUL AGE pi 4 0 3s ### Job首先创建两个并行运行的Pod计算PI $ kubectl get pods NAME READY STATUS RESTARTS AGE pi-5mt88 1/1 Running 0 6s pi-gmcq5 1/1 Running 0 6s ### 当一个Pod完成计算会进入Completed状态，就会有一个新的Pod被创建出来，并且快速地从Pending状态进入ContainerCreating状态，再到Running状态，最后完成 $ kubectl get pods NAME READY STATUS RESTARTS AGE pi-gmcq5 0/1 Completed 0 40s pi-84ww8 0/1 Pending 0 0s pi-5mt88 0/1 Completed 0 41s pi-62rbt 0/1 Pending 0 0s $ kubectl get pods NAME READY STATUS RESTARTS AGE pi-gmcq5 0/1 Completed 0 40s pi-84ww8 0/1 ContainerCreating 0 0s pi-5mt88 0/1 Completed 0 41s pi-62rbt 0/1 ContainerCreating 0 0s $ kubectl get pods NAME READY STATUS RESTARTS AGE pi-5mt88 0/1 Completed 0 54s pi-62rbt 1/1 Running 0 13s pi-84ww8 1/1 Running 0 14s pi-gmcq5 0/1 Completed 0 54s $ kubectl get pods NAME READY STATUS RESTARTS AGE pi-5mt88 0/1 Completed 0 5m pi-62rbt 0/1 Completed 0 4m pi-84ww8 0/1 Completed 0 4m pi-gmcq5 0/1 Completed 0 5m ### 所有Pod均已成功退出，SUCCESSFUL字段值变成4 $ kubectl get job NAME DESIRED SUCCESSFUL AGE pi 4 4 5m
通过上述DESIRED和SUCCESSFUL字段的关系，可以看出Job Controller控制的直接对象是Pod，Job Controller在控制循环中进行的调谐（Reconcile）操作，是根据实际在Running状态Pod数目、已经成功推出的Pod数目，以及parallelism、completions参数的值共同计算在这个周期里，应该创建或删除的Pod数目，然后调用Kubernetes API来执行这个操作
Job对象使用方法
1、外部管理器 + Job模板
把Job的YAML文件定义为一个模板，然后用一个外部工具控制这些模板来生成Job 。Job的定义方式如下所示：
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"] ### 定义了$ITEM变量 restartPolicy: Never
在控制这种Job时，只要注意如下两个方面即可
-
- 创建Job时，替换掉$ITEM这样的变量
- 所有来自同一个目标的Job，都有一个jobgroup: jobexample标签，也就是说这一组Job使用这样一个相同的标识
### 第一点可以通过shell把￥ITEM替换掉 $ mkdir ./jobs $ for i in apple banana cherry do cat job-tmpl.yaml | sed "s/$ITEM/$i/" > ./jobs/job-$i.yaml done ### 创建Job $ kubectl create -f ./jobs $ kubectl get pods -l jobgroup=jobexample NAME READY STATUS RESTARTS AGE process-item-apple-kixwv 0/1 Completed 0 4m process-item-banana-wrsf7 0/1 Completed 0 4m process-item-cherry-dnfu9 0/1 Completed 0 4m
这种模式虽然看起很傻，但却很普遍，因为大多数用户在需要管理Batch Job时，都已经有自家的一套方案，需要做的往往就是集成工作。这时候Kubernetes对这些方案最有价值的就是Job这个API对象，因此只需要编写一个外部工具（如上面for循环）来管理这些Job即可。
这种模式下使用Job对象，completions和parallelism这两个字段都应该使用默认值1，作业Pod的并行控制，应该完全交由外部工具来进行管理
2、拥有固定任务数目的并行Job
只关心最后是否有指定数目（spec.completions）个任务成功推出，不关心执行时的并行度多少。
比如上面计算pi的例子，或者可以不指定parallelism
3、指定并行度（parallelism），不设置固定的completions的值
任务总数未知，需要决定什么时候启动Pod，什么时候Job才算执行完成。因此需要一个工作队列来负责任务分发，还需要能够判断工作队列已经为空（所有工作已经结束）
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 ##工作队列采用RabbitMQ - name: QUEUE value: job2 restartPolicy: OnFailure
这个Pod执行逻辑为
/* job-wq-2 的伪代码 */ for !queue.IsEmpty($BROKER_URL, $QUEUE) { task := queue.Pop() process(task) } print("Queue empty, exiting") exit
CronJob
CronJob描述的是定时任务，举个栗子
apiVersion: batch/v1beta1 kind: CronJob metadata: name: hello spec: schedule: "*/1 * * * *" jobTemplate: spec: template: spec: containers: - name: hello image: busybox args: - /bin/sh - -c - date; echo Hello from the Kubernetes cluster restartPolicy: OnFailure
在这个YAML文件中，最重要的关键词就是jobTemplate，即一个Job对象的控制器（Controller）。如Deployment和Pod的关系一样，CronJob是一个专门用来管理Job对象的控制器。
CronJob创建和删除Job的依据是schedule字段定义的、一个标准的Unix Cron格式的表达式
如，“*/1****”，这个Cron表达式里*/1中的*表示从0开始，/表示每，1表示偏移量，它的意思就是从零开始，每1个时间单位执行一次
那时间单位又是什么意思？Cron表达式中的五个部分分别代表：分钟、小时、日、月、星期。因此上面的意思就是每分钟执行一次。
$ kubectl create -f ./cronjob.yaml cronjob "hello" created # 一分钟后 $ kubectl get jobs NAME DESIRED SUCCESSFUL AGE hello-4111706356 1 1 2s ##CronJob对象会记录下这次Job的执行时间 $ kubectl get cronjob hello NAME SCHEDULE SUSPEND ACTIVE LAST-SCHEDULE hello */1 * * * * False 0 Thu, 6 Sep 2018 14:34:00 -070
另外由于定时任务的特殊性，很可能某个Job还没有执行完，另外一个新的Job就产生了，这时候可以通过spec.concurrencyPolicy字段来定义具体的处理策略
-
- concurrencyPolicy=Allow：默认情况，Job可以同时存在；
- concurrencyPolicy=Forbid：不会创建新的Jod，该创建周期被跳过
- concurrencyPolicy=Replace：新产生的Job会替换旧的、没有执行完的Job
如果一个Job创建失败，这次创建就会被标记为“miss”，当在指定的时间窗口内，miss的数目达到100时，那么CronJob会停止创建这个Job。这个时间窗口可以由spec.startingDeadlineSeconds字段指定。
例如，startingDeadlineSeconds=200，意味着在过去的200s里，如果miss的数目到达了100次，那么这个Job就不会被创建执行了。