Kubernetes 部署的可视化地图

通过查看创建 Pod 或 Deployment 时发生的 10 个步骤，更好地理解 Kubernetes。

图片来源：

Opensource.com

当你在 Kubernetes 上使用容器时，你通常将应用程序组合在一个 Pod 中。当你启动容器或 Pod 进入生产环境时，这被称为deployment（部署）。如果你每天甚至每周都在使用 Kubernetes，你可能已经操作过数百次，但你有没有想过当你创建一个 Pod 或 Deployment 时究竟发生了什么？

我发现从宏观层面理解事件链很有帮助。当然，你不必理解它。即使你不知道为什么，它仍然可以工作。我无意列出发生的每一个细节，但我的目标是涵盖所有重要的细节。

以下是 Kubernetes 不同组件如何交互的可视化地图

图片来源：

^{(Nived Velayudhan 和 Seth Kenlon, CC BY-SA 4.0)}

你可能会在上面的图表中注意到我没有包含 etcd。API 服务器是唯一可以直接与 etcd 通信的组件，并且只有它可以对其进行更改。因此你可以假设 etcd 在此图中存在于 API 服务器的后面（隐藏）。

此外，我在这里只讨论了两个主要的控制器（Deployment 和 ReplicaSet）。其他控制器的工作方式也类似。

以下步骤描述了当你执行 kubectl create 命令时会发生什么

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

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

步骤 4 和 5： 与上一步类似，所有监视者都会收到关于 API 服务器中所做更改的通知——这次是 ReplicaSet 控制器接收到更改。控制器理解所需的副本计数和对象规范中定义的 Pod 选择器，创建 Pod 资源，并将此信息发送回 API 服务器，将其存储在 etcd 数据存储中。

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

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