k8s通过deployment部署一个pod的流程
在学习k8s工作流程之前，我们得再次认识一下上篇k8s架构与组件详解中提到的kube-controller-manager一个k8s中许多控制器的进程的集合。
比如Deployment 控制器（DeploymentController）和 Job 控制器（JobController）是 Kubernetes 内置控制器的典型例子。在 Kubernetes 中，一个控制器至少追踪一种类型的 Kubernetes 资源。这些 资源对象有一个代表期望状态的 spec 字段。该资源的控制器负责所属对象当前状态接近期望状态。
一、控制器与apiserver的交互
上面提到的这些资源的控制器是如何确保资源对象当前状态接近于期望状态？
当然是持续同步apiserver中（查询etcd）资源对象的元数据，并不断更新对象属性。是这样么？
当集群中有几十上百万个资源对象时，光控制器的http同步请求就够apiserver喝一壶的，显然不太棒。所以Kubernetes采用了一个叫Informer的机制。Informer 是 Client-go 中的一个核心工具包。
在这里informer主要实现的作用如下：
- 更快地返回 List/Get 请求，减少对 Kubenetes API 的直接调用
使用 Informer 实例的 Lister() 方法， List/Get Kubernetes 中的 Object 时，Informer 不会去请求 Kubernetes API，而是直接查找缓存在本地内存中的数据，依赖Etcd的List&Watch机制，客户端及时获知这些对象的状态变化，然后更新本地缓存，这样就在客户端为这些API对象维护了一份和Etcd数据库中几乎一致的数据，然后控制器等客户端就可以直接访问缓存获取对象的信息，而不用去直接访问apiserver。通过这种方式，Informer 既可以更快地返回结果，又能减少对 Kubernetes API 的直接调用。
- 可监听事件并触发回调函数
Informer 通过 Kubernetes Watch API 监听某种 resource 下的所有事件。Watch API 本质上就是一种 APIServer 主动向客户端推送 Kubernetes 资源修改、创建的一种机制。这样我们就可以获取到资源的变更，及时更新对象状态。
关于k8s中 informer详细可参考：kubenetes informer 详解
通过上面我们知道了控制器是通过watch api监听apiserver中资源对象的更新，下面我们进入正题：k8s工作流程。
二、k8s工作流程
我们来看通过deployment部署pod的常规流程：
image-20210914114226232
- kubectl向apiserver发送部署请求（例如使用 kubectl create -f deployment.yml）
- apiserver将 Deployment 持久化到etcd；etcd与apiserver进行一次http通信。
- controller manager通过watch api监听 apiserver ，deployment controller看到了一个新创建的deplayment对象更后，将其从队列中拉出，根据deployment的描述创建一个ReplicaSet并将 ReplicaSet 对象返回apiserver并持久化回etcd。 以此类推，当replicaset控制器看到新创建的replicaset对象，将其从队列中拉出，根据描述创建pod对象。
- 接着scheduler调度器看到未调度的pod对象，根据调度规则选择一个可调度的节点，加载到pod描述中nodeName字段，并将pod对象返回apiserver并写入etcd。
- kubelet在看到有pod对象中nodeName字段属于本节点，将其从队列中拉出，通过容器运行时创建pod中描述的容器。
上面我们说到的deployment-replicaset-pod的关系如下：
Deploy-Replica-Pod