Kubernetes系列07：Controller Manager原理分析

Controller Manager作为集群内部的管理控制中心，负责集群内的Node、Pod副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）等的管理，当某个Node意外down机时，Controller Manager会及时发现此故障并执行自动化修复流程，确保集群始终处于预期的工作状态。

Controller Manager内部包含Replication Controller、Node Controller、ResourceQuota Controller、Namespace Controller、ServiceAccount Controller、Token Controller、Service Controller及Endpoint Controller等多个Controller，每种Controller都负责一种具体的控制流程，而Controller Manager正式这些Controller的核心管理者。


1. Replication Controller

为了区分Controller Manger中的Replication Controller简写为RC，而本节中的Replication  Controller是指“副本控制器”，以便于后续分析。

Replication Controller的核心作用是确保在任何时候集群中一个RC所关联的Pod副本数量保持预设值。如果发现Pod副本数量超过预期值，则Replication Controller会销毁一些Pod副本；反之，Replication Controller会自动创建新的Pod副本，直到符合条件的Pod副本数量达到预设值。需要注意的是：只要当Pod的重启策略是Always的时候，Replication Controller才会管理该Pod的操作，在通常情况下，Pod对象被成功创建后不会消失，唯一的例外是当Pod处于successed或failed状态的时间过长（超时参数由系统设定）时，该Pod会被系统自动回收，管理该Pod的副本控制器将在其他工作节点上重新创建，运行该Pod副本。

RC中的Pod模板就像一个模具，模具制作出来的东西一旦离开模具，他们之间就再也没有关系了，同样，一旦Pod被创建完毕，无论模板如何变化，甚至换成一个新的模板，也不会影响到已经创建的Pod。此外，Pod可以通过修改它的标签来实现脱离RC的管控，该方法可以用于将Pod从集群中迁移、数据恢复等调试。对于被迁移的Pod副本，RC会自动创建一个新的副本替换被迁移的副本，需要注意的是，删除一个RC不会影响它所创建的Pod。如果想删除一个RC所控制的Pod，则需要将该RC的副本数属性设置为0，这样所有的Pod副本都会被自动删除。

我们最好不要越过RC而直接创建Pod，因为Replication Controller会通过RC管理Pod副本，实现自动创建、补足、替换、删除Pod副本，这样能提高系统的容灾能力，减少由于节点崩溃等意外状况造成的损失。即使你的应用程序只用到一个Pod副本，我们也强烈建议使用RC来定义Pod。

总结Replication Controller职责：

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

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

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

使用场景：

（1）重新调度（Rescheduling）如前面所说，不管你想运行1个副本还是1000个副本，副本控制器都能确保指定数量的副本存在于集群中，即使发生节点故障或Pod副本被终止运行等意外状况。

（2）弹性伸缩（Scaling）手动或通过自动扩容代理修改副本控制器的spec.replicas属性值，非常容易实现扩大或缩小副本的数量。

（3）滚动更新（Rolling Updates）副本控制器被设计成通过逐个替换Pod的方式来辅助服务的滚动更新，推荐的方式是创建一个新的只有一个副本的RC，若新的RC副本数量加1，则旧的RC的副本数量减1，直到这个旧的RC的副本数量为零，然后删除该旧的RC。通过上述模式，即使在滚动更新的过程中发生了不可预料的错误，Pod集合的更新也都在可控的范围内。在理想情况下，滚动更新控制器需要将准备就绪的应用考虑在内，并保证在集群中任何时刻都有足够数量的可用Pod

2. Node Controller

kubelet进程在启动时通过API Server注册自身的节点信息，并定时向API Server汇报状态信息，API Server接收到这些信息后，将这些信息更新到etcd中，etcd中存储的节点信息包括节点健康状况、节点资源、节点名称、节点地址信息、操作系统版本、Docker版本、kubelet版本等。节点健康状况包含“就绪”“未就绪”“未知”三种。

Node Controller通过API Server实时获取Node的相关信息，实现管理和监控集群中的各个Node节点的相关控制功能。

关键流程：

（1）Controller Manager在启动时如果设置了--cluster-cidr参数，那么为每个没有设置spec.PodCIDR的Node节点生成一个CIDR地址，并用该CIDR地址设置节点的spec.PodCIDR属性，这样做的目的是防止冲突。

（2）逐个读取节点信息，多次尝试修改nodeStatusMap中的节点状态信息，将该节点信息和Node Controller的nodeStatusMap中保存的节点信息做比较。如果判断出没有收到kubelet发送的节点信息、第一次收到节点信息，或在该处理过程中节点状态变成非“健壮”状态，则在nodeStatusMap中保存该节点的状态信息，并用Node Controller所在节点的系统时间作为探测时间和节点状态变化时间。如果判断出在指定时间内收到新的节点信息，且节点状态发生变化，则在nodeStatusMap中保存该节点的状态信息，并用Node
Controller所在节点的心痛时间作为探测时间和节点状态变化时间，如果判断出在指定时间内收到新的节点信息，但节点状态没有发生变化，则在nodeStatusMap中保存该节点状态变化时间作为该节点的状态变化时间。如果判断处在某一时间内没有收到节点状态信息，则设置节点状态“未知”，并且通过API Server保存节点状态。

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


3.ResourceQuota Controller

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

kubernetes支持如下三个层次的资源配额管理：

（1）容器级别：可以对CPU和Memory进行限制

（2）Pod级别：可以对一个Pod内所有容器的可用资源进行限制

（3）Namespace级别，为Namespace（多租户）级别的资源限制，包括

    Pod数量；

    Replication Controller数量；

    Service数量；

    ResourceQuota数量；

    Secret数量；

    可持有的PV（Persistent Volume）数量；

kubernetes的配额管理是通过Admission Control（准入控制），当前提供两种方式的配额约束，分别是LinitRanger与ResourceQuota，其中LimitRanger作用于Pod和Container上，而ResourceQuota则作用于Namespace上，限定一个Namespace里的各类资源的使用总额。

4.Namespace Controller

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

当Namespace的状态被设置为“Terminating”后，由Admission Controller的NamespaceLifecycle插件来阻止为该Namespace创建新的资源。同时，在Namespace Controller删除完该Namespace中的所有资源对象后，Namespace Controller对该Namespace执行finalize操作，删除Namespace的spec.finalizers域中的信息。

如果Namespace Controller观察到Namespace设置了删除期限，同时Namespace的spec.finalizers域值是空的，那么Namespace Controller将通过API Server删除该Namespace资源。

5.Service Controller 与 Endpoint Controller

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

Endpoints Controller负责监听Service和对应的Pod副本的变化，如果监测到Service被删除，则删除和该Service同名的Endpoints对象；如果监测到新的Service被创建或者修改，则根据该Service信息获得相关的Pod列表，然后创建或者更新Service对应的Endpoints对象。如果监测到Pod的事件，则更新它所对应的Service的Endpoints对象（增加、删除或者修改对应的Endpoint条目）每个Node上的kube-proxy进程会使用Endpoints对象，kube-proxy进程获取每个Service的Endpoints，实现了Service的负载均衡功能。

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