赞
踩
声明:本文为《Kubernetes权威指南:从Docker到Kubernetes实践全接触(第5版)》的读书笔记
Kubernetes从1.2版本开始支持批处理类型的应用,我们可以通过Kubernetes 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 | pod的数量少于work item | 用户程序是否要做相应的修改 | kubernetes是否支持 |
---|---|---|---|---|
Job Template Expansion | / | / | 是 | 是 |
Queue with Pod Per Work Item | 是 | / | 有时候需要 | 是 |
Queue with Variable Pod Count | 是 | / | / | 是 |
Single Job with Static Work Assignment | 是 | / | 是 | / |
考虑到批处理的并行问题,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成功结束。 |
首先是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
在这种模式下需要一个任务队列存放Work item
,比如RabbitMQ
客户端程序先把要处理的任务变成Work item
放入任务队列,然后编写Worker
程序、打包镜像并定义成为Job
中的Work Pod
。
Worker
程序的实现逻辑是从任务队列中拉取一个Work item
并处理, 在处理完成后结束进程。并行度为2的Demo如下图所示:
由于这种模式下,Worker
程序需要知道队列中是否还有等待处理的Work item
,如果有就取出来处理,否则就认为所有工作完成并结束进程,所以任务队列通常要采用Redis或者数据库来实现:
本文主要讲解Pod
批处理调度的一些概念,根据Worker Item
以及Job
的关系,主要分为 “Job Template Expansion”、“Queue with Pod Per Work Item”、“Queue with Variable Pod Count” 这三种,并简单阐述了其原理及案例,希望能帮助到大家,谢谢大家的阅读,本文完!
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。