【】nginx request body读取流程详解( 二 )
文章图片
答案就是期望的完成数量不同 ， 如果Completions不设定 ， 则实际上Job控制器发现有任一一个Pod成功并且当前活跃的Pod的数量为0 ， 则表示当前任务完成, 该模式主要适用于单次的批任务 ， 即本次批任务的所有Pod任务都完成 ， 通常也意味着本次批任务是有限的集合
而Completions设定为数量则意味着只需要完成指定数量的批任务 ， 即任务可能类似于流处理模式 ， 本次只期望完成一部分即可 ， 即Completions设定数量的任务2.4 并行策略
并行策略主要是指的如果我们指定的Parallelism的数量过大 ， 为了避免单个任务同时创建大量的Job任务对集群带来的影响则采用分批逐次递增的策略 ， 逐步完成并行所需要的Pod的更新2.5 期望计数
文章图片
文章图片
期望计数是k8s中控制器常见的机制 ， 即当控制器进行Pod操作完成后 ， 会设定当前期望的Pod的增加或者删除的计数 ， 通过期望计数的统计来确定当前是否需要继续更新对应的pod, 期望的满足主要来源于两个地方：informer和当前控制流 ， informer通过监听apiserver来感知事件 ， 而当前控制流则主要是在操作Pod失败的时候 ， 直接更新期望 ， 因为这些操作失败的Pod并不会从后续的informer中感知到2.6 删除策略
我们提到过期望计数来决定是否更新状态 ， 但这个并不保证一致性 ， 很有可能因为事件的延迟导致控制器创建了大量的Pod此时就需要基于终态的继续调整 ， 即需要根据当前的数量来删除部分的Pod, 删除策略主要是包含六点：1)未分配优先 2)未运行优先 3）未就绪优先 4）运行时间最短优先 5）重启次数多优先 6）创建时间较短优先3. 总结
文章图片
文章图片
【【】nginx request body读取流程详解】Job控制器的实现设计上还是很好玩的 ， 主要是是面向常见的批处理场景 ， 但本身并没有考虑优先级、关系、效率、分片等功能 ， 只是一个通用的基础的任务调度的实现 ，当前k8s中还有很多针对不同场景的专用任务调度实现 ， 但基于k8s的任务系统设计本身就给我们降低了很多的复杂度 ， 这也就是云原生带来的好处 ， 今天就到这里 ， 谢谢大家
