k8s教程（19）-pod之批处理调度

文章目录

• ​​01 引言​​
• ​​02 批处理调度​​

• ​​2.1 任务模式分类​​

• ​​2.1.1 按实现方式分类​​
• ​​2.1.2 按批处理并行分类​​

• ​​2.1 案例​​

• ​​2.1.1 Job Template Expansion案例​​
• ​​2.1.2 Queue with Pod Per Work Item案例​​
• ​​2.1.3 Queue with Variable Pod Count案例​​

• ​​03 文末​​

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