一起学习Kubernetes:Pod和工作负载概述

工作负载是在 Kubernetes 上运行的应用程序。在 Kubernetes 中，无论你的负载是由单个组件还是由多个一同工作的组件构成，你都可以在一组 Pod 中运行它。 在 Kubernetes 中，Pod 代表的是集群上处于运行状态的一组容器的集合（感觉称之为容器组更合适）。

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

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

以部署一个Deployment的执行过程如下图所示：

步骤1：使用kubectl create命令时，HTTP POST 请求将发送到包含部署清单的 API 服务器。API 服务器将其存储在 etcd 数据存储中，并向 kubectl 返回响应。

步骤 2 和 3：API 服务具有监视机制，所有监视此机制的客户端都会收到通知。客户端通过打开与 API 服务器的连接来监视更改，API 服务器流式传输通知。其中一个客户端是 Deployment 控制器。Deployment 控制器检测 Deployment 对象，并使用 Deployment 的当前Spec创建一个 ReplicaSet。此资源被发送回 API 服务器，API 服务器将其存储在 etcd 数据存储中。

步骤 4 和 5：与上一步类似，所有观察程序都会收到有关在 API 服务器中所做的更改的通知，这一次 ReplicaSet 控制器将选取更改。控制器了解对象Spec中定义的所需副本计数和 Pod 选择器，创建 Pod 资源，并将此信息发送回 API 服务器，将其存储在 etcd 数据存储中。

步骤 6 和 7：Kubernetes 现在拥有运行 Pod 所需的所有信息，但 Pod 应该在哪个节点上运行？调度程序会监视尚未为其分配节点的 Pod，并开始对所有节点进行过滤和排序，以选择运行 Pod 的最佳节点。选择节点后，该信息将添加到 Pod Spec中，然后发送回 API 服务器并存储在 etcd 数据存储中。

步骤 8、9 和 10：到目前为止，所有步骤都发生在控制平面本身中。工作器节点尚未执行任何工作。但是，Pod 的创建不是由控制平面处理的。相反，在所有节点上运行的 kubelet 服务会监视 API 服务器中的 pod 规范，以确定它是否需要创建任何 pod。在调度器选择的节点上运行的 kubelet 服务获取 pod spec，并指示 worker 节点中的容器运行时创建容器，容器运行时下载容器映像（如果尚不存在）并运行容器。

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 都可用时才执行操作（比如针对某种高吞吐量的分布式任务），你可以基于定制资源实现一个能够满足这一需求的扩展，并将其安装到集群中运行。