工作负载

在 Kubernetes 中，无论你的负载是由单个组件还是由多个一同工作的组件构成， 你都可以在一组 Pod 中运行它。在 Kubernetes 中， Pod 代表的是集群上处于运行状态的一组容器的集合。

Kubernetes Pod 遵循预定义的生命周期。 例如，当在你的集群中运行了某个 Pod，但是 Pod 所在的节点出现致命错误时， 所有该节点上的 Pod 的状态都会变成失败。Kubernetes 将这类失败视为最终状态： 即使该节点后来恢复正常运行，你也需要创建新的 Pod 以恢复应用。

不过，为了减轻用户的使用负担，通常不需要用户直接管理每个 Pod。 而是使用负载资源来替用户管理一组 Pod。 这些负载资源通过配置控制器来确保正确类型的、处于运行状态的 Pod 个数是正确的，与用户所指定的状态相一致。

Kubernetes 提供若干种内置的工作负载资源：

• Deployment 和 ReplicaSet （替换原来的资源 ReplicationController）。 Deployment 很适合用来管理你的集群上的无状态应用，Deployment 中的所有 Pod 都是相互等价的，并且在需要的时候被替换。
• StatefulSet 让你能够运行一个或者多个以某种方式跟踪应用状态的 Pod。 例如，如果你的负载会将数据作持久存储，你可以运行一个 StatefulSet，将每个 Pod 与某个 PersistentVolume 对应起来。你在 StatefulSet 中各个 Pod 内运行的代码可以将数据复制到同一 StatefulSet 中的其它 Pod 中以提高整体的服务可靠性。

• DaemonSet 定义提供节点本地支撑设施的 Pod。这些 Pod 可能对于你的集群的运维是非常重要的， 例如作为网络链接的辅助工具或者作为网络插件的一部分等等。 每次你向集群中添加一个新节点时，如果该节点与某 DaemonSet 的规约匹配，则控制平面会为该 DaemonSet 调度一个 Pod 到该新节点上运行。
• Job 和 CronJob 提供不同的方式来定义一些一直运行到结束并停止的任务。 你可以使用 Job 来定义只需要执行一次并且执行后即视为完成的任务。你可以使用 CronJob 来根据某个排期表来多次运行同一个 Job。

在庞大的 Kubernetes 生态系统中，你还可以找到一些提供额外操作的第三方工作负载相关的资源。 通过使用定制资源定义（CRD）， 你可以添加第三方工作负载资源，以完成原本不是 Kubernetes 核心功能的工作。 例如，如果你希望运行一组 Pod，但要求所有 Pod 都可用时才执行操作 （比如针对某种高吞吐量的分布式任务），你可以基于定制资源实现一个能够满足这一需求的扩展， 并将其安装到集群中运行。

调度工作负载

虽然标准的工作负载资源（例如 Deployment 和 Job）用于管理 Pod 的生命周期， 但在某些场景下，你可能会有更复杂的调度需求，例如需要将几组 Pod 作为一个单元整体来处理。

Workload API 允许你定义一组 Pod， 并对其应用高级的调度策略，例如成组调度。 在需要“全有或全无”的调度方式时，这对于批处理和机器学习类工作负载尤其有用。

接下来

除了阅读了解每类 API 资源方便管理工作负载外，你还可以了解如何运行以下特定任务：

• 使用 Deployment 运行一个无状态的应用
• 以单实例或者多副本集合的形式运行有状态的应用；
• 使用 CronJob 运行自动化的任务

要了解 Kubernetes 将代码与配置分离的实现机制，可参阅配置节。

关于 Kubernetes 如何为应用管理 Pod，还有两个支撑概念能够提供相关背景信息：

• 垃圾收集机制负责在对象的属主资源被删除时在集群中清理这些对象。
• Time-to-Live 控制器会在 Job 结束之后的指定时间间隔之后删除它们。

一旦你的应用处于运行状态，你就可能想要以 Service 的形式使之可在互联网上访问；或者对于 Web 应用而言，使用 Ingress 资源将其暴露到互联网上。