一张图搞懂 Pod 创建背后发生了什么？

当你创建一个 pod/deployment 时，幕后究竟发生了什么？下面将尝试将重要事件串起来：

注意到，在上图中我没有包含 etcd。原因很简单，API server 是唯一可以直接与 etcd 对话的组件，并且只有它可以对其进行更改。因此，您可以假设 etcd 位于 API server 后面并隐藏在此图中。另外，我在这里只谈论两个主要控制器，其他控制器也将以类似的方式工作。

下面让我们了解执行 kubectl create 命令后的事件链：

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

第 2 步和第 3 步： API server 有一个 watch 机制，所有 watch 客户端会收到通知。这些客户端之一是 Deployment 控制器。Deployment 控制器检测到一个 Deployment 对象，并使用 Deployment 的当前规范创建一个 ReplicaSet。该资源被发送回 API server，API server 将其存储在 etcd 数据存储中。

第 4 步和第 5 步： 与上一步类似，所有观察者都会收到有关 API Server 中所做更改的通知，这一次更改由 ReplicaSet 控制器接收。控制器了解所需的副本数和对象规范中定义的 pod 选择器，创建 pod 资源，并将此信息发送回 API server，后者将其存储在 etcd 数据存储中。

第 6 步和第 7 步： 这是已经知道 Pod 所需的所有信息，但问题是 Pod 应该在哪个节点上运行？调度程序监视尚未分配节点的 pod，并开始将所有节点过滤和打分，以选择运行 pod 的最佳节点。一旦选择了节点，该信息将被添加到 pod 规范中，并被发送回 API Server 以将其存储在 etcd 数据存储中。

第 8、9 和 10 步： 请注意，到目前为止，所有步骤都发生在控制平面本身中，此时工作节点没有做任何事情。pod 的创建不由控制平面处理，而是运行在节点上的 kubelet 服务监视 API Server 中的 pod 规范，以检查是否需要创建 pod。在调度器选择的节点上运行的 kubelet 服务将获取 pod 规范并调用工作节点中的容器运行时创建容器。下载容器镜像（如果尚未存在）并且开始运行容器。

综上所述，应该可以帮助您大概理解 Kubernetes 中的事件流。DaemonSet 或 StatefulSet 资源对象，除了使用不同的控制器之外，pod 创建过程不变。