在Kubernetes上使用容器时，通常将应用程序分组在一个pod中。当你将一个容器或pod投入生产时，这称为部署。你有没有想过当你创建一个pod或部署时会发生什么？
笔者发现从高层次上理解事件链很有帮助。以下是Kubernetes的不同组成部分如何相互作用的图解：
你可能会注意到在上面的图表中，没有包括etcd。API服务器是唯一可以直接与etcd通信的组件，并且只有它可以对其进行更改。因此，你可以假设在这个图中，etcd（隐藏）在API服务器后面。
此外，这里只讨论两个主控制器（Deployment和ReplicaSet）。其他的工作方式类似。
以下步骤描述了执行kubectl create命令时发生的情况：
第1步：当使用kubectl create命令时，会向包含部署清单的API服务器发送一个HTTP POST请求。API服务器将其存储在etcd数据存储中，并向kubectl返回响应。
第2步和第3步：API服务器有一个监视机制，所有监视它的客户端都会得到通知。客户端通过打开到API服务器的HTTP连接来监视更改，API服务器将流式发送通知。其中一个客户端是部署控制器。部署控制器检测部署对象，并使用当前部署规范创建复制集。该资源被发送回API服务器，后者将其存储在etcd数据存储中。
第4步和第5步：与前一步类似，所有监视器都会收到API服务器中所做更改的通知，这一次ReplicaSet控制器会接收更改。控制器了解目标规范中定义的所需副本计数和pod选择器，创建pod资源，并将此信息发送回API服务器，存储在etcd数据存储中。
第6步和第7步：Kubernetes现在拥有运行pod所需的所有信息，但pod应该在哪个节点上运行呢？调度器监视尚未分配节点的pod，并开始对所有节点进行筛选和排序，以选择运行pod的最佳节点。一旦选择了节点，这些信息就会添加到pod规范中。它被发送回API服务器并存储在etcd数据存储中。
第8、9和10步：到目前为止，所有步骤都发生在控制平面本身。worker节点尚未执行任何工作。不过，pod的创建并不是由控制平面来处理的。相反，在所有节点上运行的kubelet服务会监视API服务器中的pod规范，以确定是否需要创建任何pod。在调度器选择的节点上运行的kubelet服务获取pod规范，并指示worker节点中的容器运行时创建容器——当一个容器镜像被下载（如果它还不存在）并且容器实际开始运行时。
了解Kubernetes部署
了解这个流程可以帮助你理解Kubernetes的许多事件。想想DemonSet或StatefulSet。除了使用不同的控制器，pod创建过程保持不变。
问问自己：如果部署被修改为一个应用的三个副本，那么导致创建pod的事件链会是什么样子？你可以参考上面的图表或列出的步骤，看懂了你就理解了Kubernetes的一个重要组成部分。