工作负载是在 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 提供若干种内置的工作负载资源：
在庞大的 Kubernetes 生态系统中，你还可以找到一些提供额外操作的第三方工作负载相关的资源。 通过使用定制资源定义（CRD），你可以添加第三方工作负载资源，以完成原本不是 Kubernetes 核心功能的工作。 例如，如果你希望运行一组 Pod，但要求所有 Pod 都可用时才执行操作（比如针对某种高吞吐量的分布式任务），你可以基于定制资源实现一个能够满足这一需求的扩展，并将其安装到集群中运行。
限 时 特 惠： 本站每日持续更新海量各大内部创业教程，一年会员只需98元，全站资源免费下载 点击查看详情
站 长 微 信： lzxmw777
