组件之间的通信
我们知道在Kubernetes集群中apiserver是整个集群的控制入口，etcd在集群中充当数据库的作用，只有apiserver才可以直接去操作etcd集群，而我们的apiserver无论是对内还是对外都提供了统一的REST API服务，包括一个8080端口的非安全服务和6443端口的安全服务。组件之间当然也是通过apiserver进行通信的，其中kube-controller-manager、kube-scheduler、kubelet是通过apiserver watch API来监控我们的资源变化，并且对资源的相关状态更新操作也都是通过apiserver进行的，所以说白了组件之间的通信就是通过apiserver REST API和apiserver watch API进行的
Pod创建工作流
下面图示为Pod的工作流程图
和上面的组件通信一致：
- 第一步，kubelet将yaml发送给API
- 第二步通过
apiserver REST API经过KubeConfig认证通过后，创建一个Pod - 然后
apiserver接收到数据后将数据写入etcd中 - 由于
kube-scheduler通过apiserver watch API一直在监听资源的变化，这个时候发现有一个新的Pod，但是这个时候该Pod还没和任何Node节点进行绑定，所以kube-scheduler就经过一系列复查的调度策略，选择出一个合适的Node节点，将该Pod和该目标Node绑定，当然也会更新到etcd中去 - 这个时候一个的目标
Node节点上的kubelet通过apiserver watch API检测到有一个新的Pod被调度过来了，他就将该Pod的相关数据传递给后面的容器进行时container runtime,比如Docker,让他们去运行该Pod，调用CNI接口创建Pod网络，调用CRI启动容器，调用CSI进行存储卷的挂载 - 而且
kubelet还会通过container runtime获取Pod的状态，网络，容器，存储创建完成后Pod创建完成，等业务进程启动后，Pod运行成功，然后更新到apiserver中，当然最后也是写入到etcd中去的
Deploy创建工作流
- 第一步，kubelet将yaml发送给API
- 第二步通过
apiserver REST API经过KubeConfig认证通过后，创建一个Pod - 然后
apiserver接收到数据后将数据写入etcd中 - 由于
controller manager通过apiserver watch api一直监听资源的变化，这个时候deployment controller发现了一个新的deplayment对象更后，根据deployment的描述创建一个ReplicaSet并将ReplicaSet对象返回apiserver并持久化回etcd。 - 由于
kube-scheduler通过apiserver watch API一直在监听资源的变化，这个时候发现有一个新的Pod，但是这个时候该Pod还没和任何Node节点进行绑定，所以kube-scheduler就经过一系列复查的调度策略，选择出一个合适的Node节点，将该Pod和该目标Node绑定，当然也会更新到etcd中去。 - 这个时候目标
Node节点上的kubelet通过apiserver watch API检测到有一个新的Pod被调度过来了，他就将该Pod的相关数据传递给后面的容器进行时container runtime,比如Docker,让他们去运行该Pod，调用CNI接口创建Pod网络，调用CRI启动容器，调用CSI进行存储卷的挂载 - 而且
kubelet还会通过container runtime获取Pod的状态，网络，容器，存储创建完成后Pod创建完成，等业务进程启动后，Pod运行成功，然后更新到apiserver中，当然最后也是写入到etcd中去的。
