k8s 集群 Job 负载反对多个 Pod 牢靠并发执行，如何权衡利弊抉择适宜的并行计算模式？
简略聊聊你对工作负载 Job 的了解？Job 反对多个 Pod 牢靠的并发执行，如何权衡利弊抉择适宜的并行计算模式？Job 管制并行理解吗？为什么线上理论并行性可能比并行性申请略大或略小？
囧么肥事 - 胡言乱语
简略聊聊你对工作负载 Job 的了解？
在说工作负载 Job 执行原理之前，先理解下为什么会须要 Job 负载？
对于 ReplicaSet、ReplicationController 等持久性负载 来说，它们的职责是让 Pod 保留预期的正本数量，稳固长久运行。
除非被动去更改模板，进行扩缩操作，否则这些 Pod 始终长久运行，并且 运行的是持久性工作 ，比方Nginx，MySQL 等。
咦？长久工作，那么万事万物有绝对面，太极分阴阳，同样，工作除了长久工作外，也有非长久工作。
身边哪些是非长久工作呢？
咱们在日常的工作中常常都会遇到一些须要进行 批量数据处理和剖析、或者是依据工夫调度的需要 ，这些属于 短期性质的工作 。不须要长久运行，仅执行一次就完结。例如进行 数据库跨库同步，热点数据统计分析 等。也能够在特定工夫调度单个工作，例如你想调度低沉闷周期的工作。
这些执行实现就完结，实现了咱们 设定的某个指标就能够终止的，咱们划分为非长久工作。
好了，既然晓得了工作划分，而且 k8s 中 ReplicaSet、ReplicationController 等持久性负载 是保障 Pod 稳固长久运行，那么对抗的，Job 负载的职责就是 保障非长久工作在生命周期内达成使命后体面终止。
须要 Job 负载，其实就是对持久性负载的补充。
简略来说：“Pod，你去实现你的工作，实现之后我给你个体面的完结”。
过眼云烟 这个成语形容 Job 负载治理的 Pod 十分适合。昙花的指标是绽开，绽开结束后立即凋零。Job Pod 实现工作，终结，刚刚好😂。
接下来说说 Job 负载工作原理
Job 负载会创立一个或者多个 Pods，执行指标工作，在节点硬件生效或者重启状况下将持续重试 Pods 的执行，直到指定数量的 Pods 胜利终止。
随着 Pods 胜利完结，Job 跟踪记录胜利实现的 Pods 个数。当数量达到指定的胜利个数阈值时，工作（即 Job）完结。
删除 Job 的操作会革除所创立的全副 Pods。
挂起 Job 的操作会删除 Job 的所有沉闷 Pod，直到 Job 被再次复原执行。
Job 反对多个 Pod 牢靠的并发执行，如何权衡利弊抉择适宜的并行计算模式？
并行计算的模式有好多种，每种都有本人的强项和弱点，如何衡量抉择？
讲个小故事，你是团队组长，手底下有三个得力助手，囧囧，大肥，阿三。
某天，有个重要的我的项目须要差遣一位助手去洽谈，你须要从中抉择一位，他们三个各有优缺点，你须要权衡利弊抉择一位。
囧囧，长处：工作负责，技能熟练，技术型人才，毛病，外向
大肥，长处：工作久，经验丰富，为人圆滑，经验型人才，毛病：太傲娇
阿三，长处：社交能力强，伶牙俐齿，社交天花板型人才，毛病：技能绝对差些
如果你作为组长，这次是跟客户洽谈单干事宜，你会差遣哪位小可爱呢？😁😁😁
好了，说完小故事，接下来话题回到 Job 负载。
Kubernetes Job 能够用来反对 Pod 的并发执行，然而呢？须要留神的是，Job 对象并非设计为反对须要严密互相通信的 Pod 的并发执行，例如科学计算。
Job 对象反对 并发解决一系列互相独立然而又互相关联的工作工作，例如：文件转码，发送邮件，渲染视频帧等
延长：Job 有三种执行形式，能简略说说是什么吗？
第一种：非并行 Job特点😈
通常只启动一个 Pod，除非该 Pod 失败，会启动代替正本，当 Pod 胜利终止时，立刻视 Job 为实现状态。
简略了解非并行 Job，Job 启动后，只运行一个 Pod，Pod 胜利运行完结后整个 Job 也就立即完结
能够不设置 spec.completions 和 spec.parallelism。这两个属性都不设置时，均取默认值 1。
第二种：具备确定实现计数的并行 Job特点😈
Job 用来代表整个工作，当胜利的 Pod 个数达到 .spec.completions 时，Job 被视为实现
对于 确定实现计数 类型的 Job，应该设置 .spec.completions 为 所须要的实现个数，.spec.completions 字段设置为非 0 的正数值，你能够设置 .spec.parallelism，也能够不设置，其默认值为 1。
第三种：带工作队列的并行 Job特点😈
多个 Pod 之间必须 互相协调 ，或者借助内部服务 确定每个 Pod 要解决哪个工作条目
对于一个工作队列 Job，不设置 spec.completions，默认值为 .spec.parallelism，但要将.spec.parallelism 设置为一个非负整数。
例如，任一 Pod 都能够从工作队列中取走最多 N 个工作条目
每个 Pod 都能够独立确定其它 Pod 是否已实现，进而确定 Job 是否实现
当感知到 Job 中任何一个 Pod 胜利终止，Job 负载不再创立新 Pod
一旦至多 1 个 Pod 胜利实现，并且所有 Pod 都已终止，即可宣告 Job 胜利实现
一旦任何 Pod 胜利退出，任何其它 Pod 都不应再对此工作执行任何操作或生成任何输入，所有 Pod 都应启动退出过程理解完 Job 惯例执行形式，上面回归正题，如何权衡利弊抉择适宜的并行计算模式？
先看看常见并行模式计划
第一种模式，从 Job 负载的角度比照思考
单对单
每个工作任务分配一个 Job 负载单对多
一个 Job 负载负责所有工作工作比照后果：
单对单，每个工作工作一个 Job 对象，能够专一工作，然而会给用户带来一些额定的累赘，零碎须要治理大量的 Job 对象；
单对多，每个工作工作一个 Job 对象，更适宜解决大量工作工作的场景，节约开销；
第二种模式，从 Pod 数量比照思考
单对单
创立与工作工作相等的 Pod单对多
每个 Pod 能够解决多个工作工作比照后果
单对单，Pod 的数量与工作工作的数量相等，通常不须要对现有代码和容器做较大改变；
单对多，每个 Pod 能够解决多个工作工作，更适宜解决大量工作工作的场景，节约开销；
第三种模式，联合队列服务
须要运行一个队列服务
须要对已有的程序或者容器做批改，以便其能够配合队列工作
如果是一个已有的程序，革新时可能存在难度
与之比拟，其余计划在批改现有容器化利用以适应需要方面可能更容易一些
总结：通过三种模式的简略比照，首先在调配 Job 个数的时候，如果思考到任务量较小，而且须要专一于每个工作的进行，那么抉择单 Job，如果任务量较多，思考节约资源的状况下，抉择应用一个 Job 来解决大量工作。从 Pod 档次思考，则要多 剖析一下现有利用的代码改变老本和容器的革新老本 ，如果改变较大，工作数量还能接管的状况下，那么倡议抉择单对单，为每个任务分配一个 Pod 即可，工作执行结束资源回收。然而如果 任务量微小，在短期要求实现，资源储备量无限的状况下，倡议单对多，每个 Pod 解决多个工作。
至于联合队列服务，通常对现有程序的改变量较大，而且队列生产调配上须要依据理论状况进行占比思考，是否存在程序生产问题，是否存在一致性问题等等，非非凡业务须要，倡议不轻易思考，老本较高（工夫，工作量，革新难度，资源分配等等综合都较高）。
Job 管制并行理解吗？为什么线上理论并行性可能比并行性申请略大或略小？
Job 并行性：指定是同一时刻处于运行状态，解决工作的 Pods 个数。
并行性申请（.spec.parallelism）能够设置为任何非负整数。
如果未设置，则默认为 1。如果设置为 0，则 Job 相当于启动之后便被暂停，直到设置 >0理论并行性（在任意时刻运行状态的 Pods 个数）可能比并行性申请略大或略小，起因如下：
- 对于确定实现计数 Job，实际上并行执行的 Pods 个数不会超出残余未实现的工作数。
- 对于 工作队列 Job，有任何 Job 胜利完结之后，不会再有新的 Pod 启动。不过，剩下的 Pods 会继续执行结束。
- Job 控制器没有来得及作出响应，Pods 个数可能比申请的数目大，也可能小。
- Job 控制器因为任何起因（例如，短少
ResourceQuota或者没有权限）无奈创立 Pods。 - Job 控制器可能会因为之前 同 一 Job 中 Pod 生效次数过多而压抑新 Pod 的创立。
- 当 Pod 处于体面终止过程中，须要肯定工夫能力进行。
Kubernetes 举荐学习书
Kubernetes 权威指南 PDF
链接:https://pan.baidu.com/s/11huL… 提取码:sa88
k8s 系列所有问题更新记录：GitHub