Kubernetes的控制流程即Kubernetes集群中资源的增、删、改、查流程。这里的资源包括集群基础设施层面的资源和集群中应用负载层面的资源。
集群基础设施层面的资源的控制流程
Kubernetes集群基础设施层面的资源包括控制节点和计算节点，这两种节点在集群中扮演的角色不同，集群对它们的控制也不同。
1）控制节点的控制流程：在生产环境中，搭建高可用Kubernetes集群时才需要对控制节点进行控制。在Kubernetes集群中，可以人为介入增加或删除控制节点，但不可以通过某个控制节点增加或删除其他控制节点。
2）计算节点的控制流程：在Kubernetes集群中，可通过Kubeadm和Kubectl对集群中的计算节点进行控制。一般使用Kubeadm对集群中的计算节点进行增加或删除，使用Kubectl对集群中的计算节点进行查询，也可以使用Kubectl对集群中的计算节点进行修改和删除，但很少这么用。
1. 控制节点的控制流程
控制节点的控制流程如图4-3所示。
图4-3 控制节点的控制流程
由图4-3可知，在Kubernetes集群中，我们可以通过对控制节点的控制使集群中的控制节点从单个增加到多个（控制节点数为2n-1，n是大于1的整数），也可以使集群中的控制节点从多个减少到单个。在调整控制节点个数的过程中，集群存储组件Etcd的个数也在随之调整，因为集群中控制节点之间都是无状态的，且无法相互感知，需要借助Etcd来保证集群状态的一致性。
2. 计算节点的控制流程
计算节点的控制流程如图4-4所示。
图4-4 计算节点的控制流程
由图4-4可知，在Kubernetes集群中，可以通过计算节点控制流程使计算节点增加或减少。
1）通过计算节点的控制流程增加Kubernetes集群中的节点不需要遵守，节点数不需要遵守2n-1的规律，但目前官网要求集群中节点不能超过5000个。
2）通过计算节点的控制流程减少Kubernetes集群中的节点，节点数不需要遵守2n-1的规律。我们可以将集群中计算节点的数量减少到0个。Kubernetes集群的控制节点默认无法调度任何应用负载，需要在控制节点上消除Taint来将其打开。
集群中应用负载层面的资源的控制流程
Kubernetes集群中与应用负载相关的资源很多，包括Deployment、ReplicaSet、Pod、Service、Endpoint、Service Acount、Secret、Volume等。这些资源的控制流程基本相同，而且其中绝大部分资源是为Pod服务的，所以本节侧重分析Pod相关资源增、删、改、查的流程。
1. 资源创建流程
资源创建流程如图4-5所示。
图4-5 资源创建流程
由图4-5可知，资源创建流程具体步骤如下。
1）通过Kubectl或Restful Request将要创建的资源转化为Kube-apiserver所能接受的格式的资源对象，调用Kube-apiserver的资源创建接口将资源对象传入集群。
2）Kube-apiserver将传入集群的资源对象写入Etcd相应路径。
3）Kube-controller-manager监听到Etcd中有需要创建的资源时，调用对应的Controller将需要创建的资源写进相应的队列。
4）Kube-scheduler在需要创建的资源队列中监听到相应的资源后，会调用可用的调度算法和调度策略对可用的节点进行过滤和打分，最后选出可用的最优节点与需要创建的资源进行绑定，并调用Kube-apiserver的相应接口将调度结果写进Etcd指定的路径。
5）Kubelet监听到Etcd指定路径下有新的调度结果——需要创建的资源与节点的绑定信息，则根据调度结果在相应的节点上以应用负载或相应资源对象的方式创建资源并监控其运行状态。
2. 资源删除流程
资源删除流程如图4-6所示。
图4-6 资源删除流程
由图4-6可知，资源删除流程具体步骤如下。
1）通过使用Kubectl或Restful Request将要删除的资源转化为Kube-apiserver所能接受的格式的资源对象，调用Kube-apiserver的资源删除接口将需要删除的资源对象传入集群。
2）Kube-apiserver将传入集群的资源对象写入Etcd相应路径。
3）Kubelet监听到Etcd指定路径下有需要删除的资源时，会根据该信息检查所在节点上是否存在需要删除的资源。
4）Kubelet将所在的节点上满足条件的资源删除。
3. 资源修改流程
资源修改流程如图4-7所示。
图4-7 资源修改流程
由图4-7可知，资源修改流程具体步骤如下。
1）通过使用Kubectl或Restful Request将要修改的资源转化为Kube-apiserver所能接受的格式的资源对象，调用Kube-apiserver的资源修改接口将需要修改的资源对象传入集群。
2）Kube-apiserver将传入集群的资源对象写入Etcd相应路径。
3）Kube-controller-manager在监听到Etcd中有需要修改的资源时，会调用对应的Controller将需要修改的资源写进相应的队列。
4）Kube-scheduler在需要修改的资源队列中监听到相应的资源时，会调用可用的调度算法和调度策略对可用的节点进行过滤和打分，最后选出可用的最优节点与需要修改的资源进行绑定，并调用Kube-apiserver的相应接口将调度结果写入Etcd指定的路径。
5）Kubelet监听Etcd指定路径下新的调度结果，即需要修改的资源与节点的绑定信息，则根据该信息在绑定节点上修改相应的资源，并监控其后续运行状态。
4. 资源查询流程
资源查询流程与资源的增、删、改流程有些不同。查询的资源分两种。
1）Etcd中持久化存储的静态资源：包括集群基础设施层面的Node节点以及集群中应用负载层面的Deployment、ReplicaSet、Pod、Service、Endpoint、Service Acount、Secret、Volume等。
2）实时状态资源：包括集群基础设施层面的Node节点所占的CPU、内存等动态变化的资源，集群中应用负载层面的CPU、内存等动态变化的资源和集群中应用负载的日志等。
由图4-8可知，查询Etcd中持久化存储的资源具体步骤如下。
图4-8 Etcd中持久化存储资源的查询流程
1）通过Kubectl或Restful Request将需要查询的资源的关键信息（比如name）格式化为Kube-apiserver所能接受的格式，向Kube-apiserver发起查询持久化资源的请求。
2）Kube-apiserver根据请求发送到集群中需要查询的资源的关键信息（比如name）在Etcd指定路径下找到要查询的持久化资源并返回。
3）Kubectl或Restful Request收到查询持久化资源的响应。
由图4-9可知，查询实时状态资源的具体步骤如下。
图4-9 实时状态资源的查询流程
1）通过Kubectl或Restful Request将需要查询的资源的关键信息（比如name）格式化为Kube-apiserver所能接受的格式，向Kube-apiserver发起查询实时状态资源的请求。
2）Kube-apiserver根据请求在Etcd指定路径下找到与查询的实时状态资源对应的节点信息。
3）Kube-apiserer将实时状态资源查询请求转发到指定节点的Kubelet中。
4）指定节点的Kubelet根据请求查询相应的实时状态资源信息并返回。
5）Kubectl或Restful Request收到查询的实时状态资源。
标签：控制,Kube,流程,集群,Etcd,k8s,节点,资源 From： https://www.cnblogs.com/muzinan110/p/17066766.html