K8s系列之：job批处理调度_queue with pod per work item

K8s可以通过Job资源对象来定义并启动一个批处理任务。批处理任务通常并行或者串行启动多个计算进程去处理一批工作项(work item)，处理完成后，整个批处理任务结束。

一、批处理任务模式

按照批处理任务实现方式的不同，批处理任务可以分为如下图的几种模式：

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

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

• Queue with Variable Pod Count模式：采用一个任务队列存放Work item，一个Job对象作为消费者去完成这些Work item，但与上面的模式不同，Job启动的Pod数量是可变的。

• Single Job with Static Work Assignment的模式，也是一个Job产生多个Pod的模式，但它采用程序静态方式分配任务项，而不是采用队列模式进行动态分配。

批处理任务的模式对比

二、Job类型

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需要一个独立的Queu，Work item都在一个Queue中存放，不能设置Job的.spec.completions参数，Job有以下特性。

• 每个Pod能独立判断和决定是否还有任务项需要处理。
• 如果某个Pod正常结束，则Job不会再启动新的Pod。
• 如果一个Pod成功结束，则此时应该不存在其他Pod还在干活的情况，它们应该都处于即将结束、退出的状态。
• 如果所有的Pod都结束了，且至少有一个Pod成功结束，则整个Job算是成功结束。

三、批处理模型实例

1.Job Template Expansion模式

• Job Template Expansion模式每个Work item对应一个Job实例，这种模式首先定义一个Job模板，模板里主要的参数是Work item的标识。因为每个Job处理不同的Work item。

如下所示的Job模版(文件名为job.yaml.txt)中的$ITEM可以作为任务项的标识：

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

通过下面的操作，生成3个对应的Job定义文件并创建Job：

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

ls jobs
job-apple.yaml    job-banana.yaml  job-cherry.yaml
1
2
3
4
5
6
7

kubectl create -f jobs
job "process-item-apple" created
job "process-item-banana" created
job "process-item-cherry" created
1
2
3
4

观察Job的运行情况

kubectl get jobs -l jobgroup=jobexample
NAME         DESIRED         SUCCESSFUL     AGE
process-item-apple         1       1         4m
process-item-banana        1       1         4m
process-item-cherry        1       1         4m

1
2
3
4
5
6

2.Queue with Pod Per Work Item模式

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

3.Queue with Variable Pod Count模式

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