Job/CronJob：为什么不直接用Pod来处理业务

面向对象的设计有许多基本原则，其中有两条我认为比较恰当地描述了 Kubernetes 对象设计思路，一个是“单一职责”，另一个是“组合优于继承”。

“单一职责”的意思是对象应该只专注于做好一件事情，不要贪大求全，保持足够小的粒度才更方便复用和管理。

“组合优于继承”的意思是应该尽量让对象在运行时产生联系，保持松耦合，而不要用硬编码的方式固定对象的关系。

应用这两条原则，我们再来看 Kubernetes 的资源对象就会很清晰了。因为 Pod 已经是一个相对完善的对象，专门负责管理容器，那么我们就不应该再“画蛇添足”地盲目为它扩充功能，而是要保持它的独立性，容器之外的功能就需要定义其他的对象，把 Pod 作为它的一个成员“组合”进去。

这样每种 Kubernetes 对象就可以只关注自己的业务领域，只做自己最擅长的事情，其他的工作交给其他对象来处理，既不“缺位”也不“越位”，既有分工又有协作，从而以最小成本实现最大收益。

对应到 Kubernetes 里，“临时任务”就是 API 对象 Job，“定时任务”就是 API 对象 CronJob，使用这两个对象你就能够在 Kubernetes 里调度管理任意的离线业务了。

job 的 YAML“文件头”部分还是那几个必备字段，简单说一下：

• apiVersion 不是 v1，而是 batch/v1。
• kind 是 Job，这个和对象的名字是一致的。
• metadata 里仍然要有 name 标记名字，也可以用 labels 添加任意的标签.

列出几个控制离线作业的重要字段。

• activeDeadlineSeconds，设置 Pod 运行的超时时间。
• backoffLimit，设置 Pod 的失败重试次数。
• completions，Job 完成需要运行多少个 Pod，默认是 1 个。
• parallelism，它与 completions 相关，表示允许并发运行的 Pod 数量，避免过多占用资源。

CronJob 使用定时规则控制 Job，Job 使用并发数量控制 Pod，Pod 再定义参数控制容器，容器再隔离控制进程，进程最终实现业务功能，层层递进的形式有点像设计模式里的 Decorator（装饰模式），链条里的每个环节都各司其职，在 Kubernetes 的统一指挥下完成任务。

CronJob 除了定义 Job 对象的“jobTemplate”字段之外，CronJob 还有一个新字段就是“schedule”，用来定义任务周期运行的规则。它使用的是标准的 Cron 语法，指定分钟、小时、天、月、周，和 Linux 上的 crontab 是一样的。

此文章为7月Day13学习笔记，内容来源于极客时间《Kubernetes入门实战课》，推荐该课程。