01 引言
声明：本文为《Kubernetes权威指南：从Docker到Kubernetes实践全接触（第5版）》的读书笔记
Kubernetes从1.2版本开始支持批处理类型的应用，我们可以通过Kubernetes Job资源对象来定义并启动一个批处理任务。
02 批处理调度
批处理任务通常并行（或者串行）启动多个计算进程去处理一批工作项(Work item)，处理完成后，整个批处理任务结束。
2.1 任务模式分类
2.1.1 按实现方式分类
按照批处理任务实现方式的不同，批处理任务可以分为如图所示的几种模式：
模式分类：
| 模式名称 | 描述 |
| 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 | pod的数量少于work item | 用户程序是否要做相应的修改 | kubernetes是否支持 |
| Job Template Expansion | / | / | 是 | 是 |
| Queue with Pod Per Work Item | 是 | / | 有时候需要 | 是 |
| Queue with Variable Pod Count | 是 | / | / | 是 |
| Single Job with Static Work Assignment | 是 | / | 是 | / |
2.1.2 按批处理并行分类
考虑到批处理的并行问题，Kubernetes将Job分以下三种类型：
| 类型 | 描述 |
| Non-parallel Jobs | 通常一个Job只启动一个Pod，除非Pod异常，才会重启该Pod，一旦此Pod正常结束，Job将结束 |
| Parallel Jobs with a fixed completion count | 并行Job会启动多个Pod，此时需要设定Job的.spec.completions参数为一个正数，当正常结束的Pod 数量达至此参数设定的值后，Job结束。此外，Job的.spec.parallelism参数用来控制并行度，即同时启动几个Job来处理Work item |
| Parallel Jobs with a work queue | 任务队列方式的并行Job需要一个独 立的Queue，Work item都在一个Queue中存放，不能设置Job 的.spec.completions参数，此时Job有以下特性：① 每个Pod都能独立判断和决定是否还有任务项需要处理，如果某个Pod正常结束，则Job不会再启动新的Pod 。 ②如果一个Pod成功结束，则此时应该不存在其他Pod还在工作的情况，它们应该都处于即将结束、退出的状态。③如果所有Pod都结束了，且至少有一个Pod成功结束，则整个Job成功结束。 |
2.1 案例
2.1.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
通过下面的操作，生成了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 # kubectl create -f jobs job "process-item-apple"created job "process-item-banana"created job "process-item-cherry"created
观察Job的运行情况：
$ kubect1 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
2.1.2 Queue with Pod Per Work Item案例
在这种模式下需要一个任务队列存放Work item，比如RabbitMQ客户端程序先把要处理的任务变成Work item放入任务队列，然后编写Worker程序、打包镜像并定义成为Job中的Work Pod。
Worker程序的实现逻辑是从任务队列中拉取一个Work item并处理， 在处理完成后结束进程。并行度为2的Demo如下图所示：
2.1.3 Queue with Variable Pod Count案例
由于这种模式下，Worker程序需要知道队列中是否还有等待处理的Work item，如果有就取出来处理，否则就认为所有工作完成并结束进程，所以任务队列通常要采用Redis或者数据库来实现：
03 文末
本文主要讲解Pod批处理调度的一些概念，根据Worker Item以及Job的关系，主要分为 “Job Template Expansion”、“Queue with Pod Per Work Item”、“Queue with Variable Pod Count” 这三种，并简单阐述了其原理及案例，希望能帮助到大家，谢谢大家的阅读，本文完！
