pod调度之Job:批处理调度_批处理是并行还是串行

Kubernetes从1.2版本开始支持批处理类型的应用，我们可以通过Kubernetes Job资源对象来定义并启动一个批处理任务。
批处理任务通常 并行（或者串行） 启动多个计算进程去处理一批工作项（work item），处理完成后，整个批处理任务结束。
按照批处理任务实现方式的不同，批处理任务可以分为以下的几种模式：

1. Job Template Expansion模式：
   一个Job对象对应一个待处理的Work item，有几个Work item就产生几个独立的Job。
   通常适合Work item数量少、每个Work item要处理的数据量比较大的场景。
   比如有一个100GB的文件作为一个Work item，总共有10个文件需要处理。

2. Queue with Pod Per Work Item模式：
   采用一个任务队列存放Work item，一个Job对象作为消费者去完成这些Work item。
   在这种模式下，Job会启动N个Pod，每个Pod都对应一个Work item。

3. Queue with Variable Pod Count模式：
   也是采用一个任务队列存放Work item，一个Job对象作为消费者去完成这些Work item。
   但与上面的模式不同，Job启动的Pod数量是可变的。
   还有一种被称为Single Job with Static Work Assignment的模式，也是一个Job产生多个Pod，但它采用程序静态方式分配任务项，而不是采用队列模式进行动态分配。

考虑到批处理的并行问题，Kubernetes将Job分以下三种类型。

1. Non-parallel Jobs
   通常一个Job只启动一个Pod，除非Pod异常，才会重启该Pod，一旦此Pod正常结束，Job将结束。
2. Parallel Jobs with a fixed completion count
   并行Job会启动多个Pod，此时需要设定Job的.spec.completions参数为一个正数，当正常结束的Pod数量达至此参数设定的值后，Job结束。
   此外，Job的.spec.parallelism参数用来控制并行度，即同时启动几个Job来处理Work Item。
3. Parallel Jobs with a work queue
   任务队列方式的并行Job需要一个独立的Queue，Work item都在一个Queue中存放，不能设置Job的.spec.completions参数，此时Job有以下特性:
   1: 每个Pod都能独立判断和决定是否还有任务项需要处理。
   2: 如果某个Pod正常结束，则Job不会再启动新的Pod。
   3: 如果一个Pod成功结束，则此时应该不存在其他Pod还在工作的情况，它们应该都处于即将结束、退出的状态。
   4: 如果所有Pod都结束了，且至少有一个Pod成功结束，则整个Job成功结束。

Job Template Expansion模式

由于在这种模式下每个Work item对应一个Job实例，所以这种模式首先定义一个Job模板，模板里的主要参数是Work item的标识，因为每个Job都处理不同的Work item。
如下所示的Job模板（文件名为job.yaml.txt）中的$ITEM可以作为任务项的标识：

[root@bogon ~]# vim job.yaml.txt 

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

生成三个job.yaml

mkdir jobs

for i in apple banana cherry ;do cat job.yaml.txt  |sed "s/\$ITEM/$i/" > jobs/job-$i.yaml ;done

[root@bogon ~]# kubectl create -f jobs
job.batch/process-item-apple created
job.batch/process-item-banana created
job.batch/process-item-cherry created
1
2
3
4
5
6
7
8

查看job的运行情况

[root@bogon ~]# kubectl get jobs
NAME                  COMPLETIONS   DURATION   AGE
process-item-apple    1/1           2m27s      3m32s
process-item-banana   1/1           44s        3m32s
process-item-cherry   1/1           2m46s      3m31s

1
2
3
4
5
6

Queue with Pod Per Work Item模式

在这种模式下需要一个任务队列存放Work item，比如RabbitMQ，客户端程序先把要处理的任务变成Work item放入任务队列，然后编写Worker程序、打包镜像并定义成为Job中的Work Pod。
Worker程序的实现逻辑是从任务队列中拉取一个Work item并处理，在处理完成后即结束进程。
并行度为2的Demo示意图

Queue with Variable Pod Count模式

由于这种模式下，Worker程序需要知道队列中是否还有等待处理的Work item，如果有就取出来处理，否则就认为所有工作完成并结束进程，所以任务队列通常要采用Redis或者数据库来实现。