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” 这三种，并简单阐述了其原理及案例，希望能帮助到大家，谢谢大家的阅读，本文完！