首先，通过 kubectl 命令将准备好的 Deployment 清单 YAML 文件提交到 Kubernetes。kubectl 命令通过 HTTP POST 请求发送清单到 Kubernetes API Server。API Server 检查 Deployment 定义，存储到 etcd，返回响应给 kubectl。
Deployment Controller 生成 ReplicaSet
当新创建 Deployment 资源时，所有通过 API Server 监听机制监听 Deployment 列表的客户端马上会收到通知。其中有个客户端叫 Deployment Controller，该 Controller 是一个负责处理 Deployment 事务的活动组件。
一个 Deployment 由一个或多个 Replicaset 支持，ReplicaSet 后面会创建实际的 Pod 。当 Deployment Controller 检查到有一个新的 Deployment 对象时，会按照 Deploymnet 当前的定义创建 ReplicaSet。这包括通过 Kubemetes API 创建一个新的 ReplicaSet 资源。Deployment Controller 不会去处理单个 Pod。
ReplicaSet Controller 创建 Pod 资源
新创建的 ReplicaSet 由 ReplicaSet Controller（通过 API Server 创建、修改、删除 ReplicaSet 资源）接收。Controller 会考虑 replica 数量、ReplicaSet 中定义的 Pod Selector，然后检查是否有足够的满足 Selector 的 Pod。
而后 Controller 会基于 ReplicatSet 的 Pod 模板创建 Pod 资源（当 Deployment Controller 创建 ReplicaSet 时，会从 Deployment 复制 Pod 模板）。
Scheduler 分配节点给新创建的 Pod
新创建的 Pod 目前保存在 etcd 中，但是它们每个都缺少一个重要的东西——它们还没有任何关联节点。它们的 nodeName 属性还未被设置。Scheduler 会监控像这样的 Pod，发现一个，就会为 Pod 选择最佳节点，并将节点分配给 Pod。Pod 的定义现在就会包含它应该运行在哪个节点。
到此，所有的一切都发生在 Kubemetes 控制平面中。参与这个全过程的 Controller 没有做其它具体的事情，除了通过 API Server 更新资源。
Kubelet 运行 Pod 容器
当前，工作节点还没做任何事情，Pod 容器还没有被启动起来，Pod 容器的镜像也还没有下载。
随着 Pod 目前分配给了特定的节点，节点上的 Kubelet 终于可以工作了。Kubelet 通过 API Server 监听 Pod 变更，发现有新的 Pod 分配到本节点后，会去检查 Pod 定义，然后命令 Docker 或者任何使用的 Container Runtime 来启动 Pod 容器，Container Runtime 就会去运行容器。
文献来源
[1] LUKŠA,M. Kubernetes in Action. Shelter Island:Manning Publications Co. 2018.