无状态Pod的创建流程
我们知道无状态工作负载Deployment创建容器组，是通过控制ReplicaSet来实现的，下面我们了解下ReplicaSet创建Pod 的详细流程。
图中有三个 List-Watch，分别是 Controller Manager（运行在 Master），Scheduler（运行在 Master），kubelet（运行在 Node）。它们在进程一启动就会监听（Watch）API Server 发出来的事件。我们来看下创建的12个步骤。
- 用户通过 kubectl 或其他 API 客户端，提交请求给 API Server 来建立一个 Pod 对象副本（ReplicaSet）。
- API Server 将 Pod 对象的相关元信息存入 etcd 中，待写入操作执行完成，API Server 即会返回确认信息至客户端
- 当 etcd 接受创建 Pod 信息以后，会发送一个 Create 事件给 API Server
- 由于 Controller Manager 一直在监听（Watch，通过http的8080端口）API Server 中的事件。此时 API Server 接收到了 Create 事件，又会发送给 Controller Manager
- Controller Manager 在接到 Create 事件以后，调用其中的 ReplicaSet（简称RS）来保证 Node 上面需要创建的副本数量。一旦副本数量少于 RS 中定义的数量，RS 会自动创建副本。总之它是保证副本数量的 Controller（扩容缩容的担当）
- 在 Controller Manager 创建 Pod 副本以后，API Server 会在 etcd 中记录这个 Pod 的详细信息。例如 Pod 的副本数，Container 的内容是什么
- 同样， etcd 会将创建 Pod 的信息通过事件发送给 API Server
- 由于 Scheduler 在监听（Watch）API Server，并且它在系统中起到了“承上启下”的作用，“承上”是指它负责接收创建的 Pod 事件，为其安排 Node；“启下”是指安置工作完成后，Node 上的 kubelet 进程会接管后继工作，负责 Pod 生命周期中的“后半生”。 换句话说，Scheduler 的作用是将待调度的 Pod 按照调度算法和策略绑定到集群中 Node 上
- Scheduler 调度完毕以后会更新 Pod 的信息，此时的信息更加丰富了。除了知道 Pod 的副本数量，副本内容。还知道部署到哪个 Node 上面了。并将上面的 Pod 信息更新至 API Server，由 API Server 更新至 etcd 中，保存起来
- etcd 将更新成功的事件发送给 API Server，API Server 也开始反映此 Pod 对象的调度结果
- kubelet 是在 Node 上面运行的进程，它也通过 List-Watch 的方式监听（Watch，通过https的6443端口）API Server 发送的 Pod 更新的事件。kubelet 会尝试在当前节点上调用容器运行时启动Pod，并将 Pod 以及容器的结果状态回送至 API Server
- API Server 将 Pod 状态信息存入 etcd 中。在 etcd 确认写入操作成功完成后，API Server将确认信息发送至相关的 kubelet，事件将通过它被接受
注意：在完成Pod的创建之后，kubelet 还会一直保持监听，为什么？原因很简单，客户可能有新的请求，如kubectl 发出命令要求扩充 Pod 副本数量，那么上面的流程又会触发一遍，kubelet 会根据最新的 Pod 的部署情况调整 Node 的资源。又或者 Pod 副本数量没有发生变化，但是其中的镜像文件升级了，kubelet 也会自动获取最新的镜像文件并且加载。
