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 对象。