# Job的模式
Kubernetes Job 对象可以用来支持 Pod 的并发执行,但是:
- Job 对象并非设计为支持需要紧密相互通信的Pod的并发执行,例如科学计算
- Job 对象支持并发处理一系列相互独立但是又相互关联的工作任务,例如:
- 发送邮件
- 渲染页面
- 转码文件
- 扫描 NoSQL 数据库中的主键
- 其他
在一个复杂的系统中,可能存在多种类型的工作任务,本文只考虑批处理任务(batch job)。
对于批处理任务的并行计算,存在着几种模式,它们各自有自己的优缺点:
- 每个工作任务一个 Job 对象 v.s. 一个 Job 对象负责所有的工作任务
- 当工作任务特别多时,第二种选择(一个 Job 对象负责所有的工作任务)更合适一些
- 第一种选择(每个工作任务一个 Job 对象)将为管理员和系统带来很大的额外开销,因为要管理很多数量的 Job 对象
- Pod的数量与工作任务的数量相等 v.s. 每个Pod可以处理多个工作任务
- 第一种选择(Pod的数量与工作任务的数量相等)通常只需要对现有的代码或容器做少量的修改
- 第二种选择(每个Pod可以处理多个工作任务)更适合工作任务的数量特别多的情况,相较于第一种选择可以降低系统开销
- 使用工作队列,此时:
- 需要运行一个队列服务
- 需要对已有的程序或者容器做修改,以便其可以配合队列工作
- 如果是一个已有的程序,改造时可能存在难度
他们的优缺点归纳如下表所示,其中第二列到第四列罗列了主要考虑的对比因素:
模式 | 单个Job对象 | Pod的数量少于工作任务? | 是否无需修改已有代码? | 是否可兼容kube1.1 |
---|---|---|---|---|
Job Template Expansion (opens new window) | ✓ | ✓ | ||
Queue with Pod Per Work Item (opens new window) | ✓ | 有时候 | ✓ | |
Queue with Variable Pod Count (opens new window) | ✓ | ✓ | ✓ | |
Single Job with Static Work Assignment | ✓ | ✓ |
当您指定 .spec.completions
时,Job 控制器创建的每个 Pod 都有一个相同的 spec。这意味着,同一个 Job 创建的所有的 Pod 都使用:
- 相同的执行命令
- 相同的容器镜像
- 相同的数据卷
- 相同的环境变量(例如,不同时间点创建的Pod,Service的环境变量 可能会不同)
Job 的不同模式本质上讲,如何为一组工作任务分配 Pod。下表总结了不同的模式下 .spec.parallelism
和 .spec.completions
字段的设置。(表中 w
代表工作任务的数量)
模式 | .spec.completions | .spec.parallelism |
---|---|---|
Job Template Expansion (opens new window) | 1 | should be 1 |
Queue with Pod Per Work Item (opens new window) | W | any |
Queue with Variable Pod Count (opens new window) | 1 | Any |
Single Job with Static Work Assignment | W | any |
免费答疑
微信群
微信扫码 进群发广告者死全家...
赞赏
微信扫码