Controller Manager原理分析

Controller Manager通过API Server提供的(List-Watch)接口实时监控集群中特定资源的状态变化，当发生各种故障导致某资源对象的状态发生变化时，Controller会尝试将其状态调整为期望的状态。

Controller Manager的内部包含Replication Controller、Node Controller、ResourceQuota Controller、Namespace Controller、Service Account Controller、Token Controller、Service Controller及Endpoint Controller共8种Controller，每种Controller都负责一种特定资源的控制流程，Controller Manager是这些Controller的核心管理者。

1.Replication Controller

Replication Controller的核心作用是确保任何时候集群中某个与RC关联的Pod副本数量都保持预设值。

(1)确保在当前集群中有且仅有N个Pod实例，N是在RC中定义的Pod副本数量。

(2)通过调整RC的spec.replicas属性值来实现系统扩容或者缩容。

(3)通过改变RC中的Pod模板（主要是镜像版本）来实现系统的滚动升级。

Replication Controller的典型使用场景如下。

(1)重新调度(Rescheduling)。

不管是想运行1个副本还是1000个副本，副本控制器都能确保指定数量的副本存在于集群中，即使发生节点故障或Pod副本被终止运行等意外状况。

(2)弹性伸缩(Scaling)。

手动或者通过自动扩容代理修改副本控制器的spec.replicas属性值，非常容易实现增加或减少副本的数量。

(3)滚动更新(Rolling Updates)。

副本控制器被设计成通过逐个替换Pod的方式来辅助服务的滚动更新。

2.Node Controller

kubelet进程在启动时通过API Server注册自身的节点信息，并定时向API Server汇报状态信息，API Server在接收到这些信息后，会将它们更新到etcd中。

节点健康状况包含“就绪”(True)、“未就绪”(False)和“未知”(Unknown)3种。

Node Controller通过API Server实时获取Node的相关信息，实现管理和监控集群中的各个Node的相关控制功能，Node Controller的核心工作流程如下。

(1)Controller Manager启动阶段。

如果设置了--cluster-cidr参数，那么为每个没有设置Spec.PodCIDR的Node都生成一个CIDR地址，并用该CIDR地址设置节点的Spec.PodCIDR属性，这样做的目的是防止不同节点的CIDR地址发生冲突。

(2)逐个读取Node信息。

多次尝试修改nodeStatusMap中的节点状态信息，将该节点信息和Node Controller的nodeStatusMap中保存的节点信息进行比较。如果判断出没有收到kubelet发送的节点信息、第1次收到节点kubelet发送的节点信息，或在该处理过程中节点状态变成非“健康”状态，则在nodeStatusMap中保存该节点的状态信息，并用Node Controller所在节点的系统时间作为探测时间和节点状态变化时间。

如果判断出在指定时间内收到新的节点信息，且节点状态发生变化，则在nodeStatusMap中保存该节点的状态信息，并用Node Controller所在节点的系统时间作为探测时间和节点状态变化时间。如果判断出在指定时间内收到新的节点信息，但节点状态没发生变化，则在nodeStatusMap中保存该节点的状态信息，并用Node Controller所在节点的系统时间作为探测时间，将上次节点信息中的节点状态变化时间作为该节点的状态变化时间。

(3)逐个读取节点信息。

如果节点状态变为非“就绪”状态，则将节点加入待删除队列，否则将节点从该队列中删除。如果节点状态为非“就绪”状态，且系统指定了Cloud Provider，则Node Controller调用Cloud Provider查看节点，若发现节点故障，则删除etcd中的节点信息，并删除和该节点相关的Pod等资源的信息。

3.ResourceQuota Controller

作为完备的企业级的容器集群管理平台，Kubernetes也提供了ResourceQuota Controller（资源配额管理）这一高级功能，资源配额管理能够确保指定的资源对象在任何时候都不会超量占用系统物理资源，避免了由于某些业务进程的设计或实现的缺陷导致整个系统运行紊乱甚至意外宕机，对整个集群的平稳运行和稳定性具有非常重要的作用。

目前Kubernetes支持以下3个层次的资源配额管理。

(1)容器级别，可以对CPU和Memory进行限制。

(2)Pod级别，可以对一个Pod内所有容器的可用资源进行限制。

(3)Namespace级别，为Namespace（多租户）级别的资源限制。

4.Namespace Controller

用户通过API Server可以创建新的Namespace并将其保存在etcd中，Namespace Controller定时通过API Server读取这些Namespace的信息。如果Namespace被API标识为优雅删除（通过设置删除期限实现，即设置DeletionTimestamp属性），则将该Namespace的状态设置成Terminating并保存到etcd中。同时Namespace Controller删除该Namespace下的Service Account、RC、Pod、Secret、PersistentVolume、ListRange、 ResourceQuota和Event等资源对象。

5.Service Controller

Service Controller其实是属于Kubernetes集群与外部的云平台之间的一个接口控制器。Service Controller监听Service的变化，如果该Service是一个LoadBalancer类型的Service(externalLoadBalancers=true)，则Service Controller确保在外部的云平台上该Service对应的LoadBalancer实例被相应地创建、删除及更新路由转发表（根据Endpoints的条目）。

6.Endpoints Controller

Endpoints表示一个Service对应的所有Pod副本的访问地址，Endpoints Controller就是负责生成和维护所有Endpoints对象的控制器。

Endpoints Controller负责监听Service和对应的Pod副本的变化，如果监测到Service被删除，则删除和该Service同名的Endpoints对象。如果监测到新的Service被创建或者修改，则根据该Service信息获得相关的Pod列表，然后创建或者更新Service对应的Endpoints对象。