K8s-为什么使用 Job 而不是直接使用 Pod？

由于Pod比容器更能代表实际应用，因此K8s并没有在容器层面编排服务，而是以Pod作为集群中调度运维的最小单位。

我们还看到了一张K8s的资源对象关系图，以Pod为中心，延伸出了很多代表各种业务的其他资源对象。我们再看一下：

你可能会有这样的疑问：Pod的功能已经足够完整了，为什么还要定义这些额外的对象呢？为什么不直接向 Pod 添加功能来处理业务需求呢？

这个问题体现了Google对于大规模计算集群管理的深刻思考。今天我们就从最简单的两个对象——Job和CronJob开始聊聊K8s基于Pod的设计理念。

为什么不直接使用 Pod

现在你应该知道，K8s 使用的是 RESTful API，它将集群中的各种业务抽象为 HTTP 资源对象。那么在这个层面上，我们就可以用面向对象的方式来解决问题了。

如果您有一定的编程经验，您就会知道面向对象编程（OOP），它将所有事物视为高度内聚的对象，并强调对象之间相互通信以完成任务。

面向对象设计的基本原则有很多，我认为其中有两条更贴切地描述K8s的对象设计，一是“单一职责”，二是“组合优于继承”。

“单一职责”是指对象只专注于做好一件事，而不是贪图一切。保持粒度足够小，更方便复用和管理。

“组合优于继承”意味着对象在运行时应该尽可能地连接起来以保持松散耦合，而不是硬编码对象之间的关系。

应用这两个原则，我们就会很清楚地看到K8s的资源对象。因为Pod已经是一个比较完整的对象，专门负责管理容器，那么我们不应该再盲目地为它扩展功能，而是为了保持它的独立性，容器之外的功能需要定义其他功能对象，“组合”Pod作为其成员之一。