《Kubernetes知识篇：Kube-controller-manager原理分析》

---

一、Controller Manager结构图

controller manager作为集群内部的管理控制中心，负责集群内Node、Pod副本、服务端Endpoint、服务账号（ServiceAccount）、命名空间（Namespace）、资源定额（Resoucequota）等的管理，当某一个节点宕机时，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的核心管理者。

结构图如下所示：

每个Controller通过API Server提供的接口实时监控整个集群的每个资源对象的当前状态，当发生各种故障导致系统状态发生变化时，会尝试将系统状态修复到“期望状态”。

---

二、Replication Controller

为了区分Controller manager中的Replication Controller（副本控制器）和资源对象的Replication Controller，这里将资源对象简称为RC，而这里的Replication Controller指的是副本控制器。

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

注意：
1、只有当Pod的重启策略是Always的时候（RestartPolicy=Always），副本控制器才会管理该Pod的操作（创建、销毁、重启等）。在不指定重启策略时，默认使用always。
2、RC 中的Pod模板就像一个模具，模具制造出来的东西一旦离开模具，他们之间就没有关系了。同理，一旦Pod被创建出来，无论模板怎么变化，都不会影响之前创建的Pod。
3、最好不要越过RC而直接创建Pod，因为Replication Controller会通过RC管理Pod副本，实现自动创建、补足、替换、删除Pod副本，可以提高系统容灾能力，减少由于节点崩溃等意外造成的损失。
4、Pod可以通过修改label来脱离RC的管控，该方法可以用于将Pod从集群中迁移，数据修复等调试。
5、删除一个RC不会影响它所创建的Pod，如果要删除Pod需要将RC的副本数属性设置为0。

Replication Controller职责
1、确保集群中有且仅有N个Pod实例，N是RC中定义的Pod副本数量。
2、通过调整RC中的spec.replicas属性值来实现系统扩容或缩容。
3、通过改变RC中的Pod模板（主要是镜像版本）来实现系统的滚动升级。

Replication Controller典型使用场景
1、重新调度（Rescheduling）：当发生节点故障或Pod被意外终止运行时，可以重新调度保证集群中仍然运行指定的副本数。
2、弹性伸缩（Scaling）：通过手动或自动扩容代理修复副本控制器的spec.replicas属性，可以实现弹性伸缩。
3、滚动更新（Rolling Updates）：创建一个新的RC文件，通过kubectl 命令或API执行，则会新增一个新的副本同时删除旧的副本，当旧副本为0时，删除旧的RC。

---

三、Node Controller

kubelet进程启动时会通过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属性，防止不同的节点的CIDR地址发生冲突。

2、逐个读取节点信息，如果节点状态变成非“就绪”状态，则将节点加入待删除队列，否则将节点从该队列删除。

如下图所示：

---

四、ResourceQuota Controller

作为完备的企业级容器管理平台，Kubernetes提供了资源配额管理（ResourceQuota）这一高级功能，资源配额管理确保指定的资源对象在任何时候都不会超量占用系统物理资源。

支持如下三个层次的资源配额管理
1、容器级别：可以对cpu和memory进行限制
2、Pod级别：可以对一个pod内所有容器的可用资源进行限制
3、Namespace级别：为Namespace（多租户）的级别资源限制，包括如下所示：
  Pod数量
  Replication Controller数量
  Service数量
  ResourceQuota数量
  Secret数量
  可持有的PV（Persistent Volume）数量

说明：
  k8s配额管理是通过Admission Control（准入控制）来控制的。
  Admission Control提供两种配额约束方式：LimitRanger和ResourceQuota
  LimitRanger作用于Pod和Container。
  ResourceQuota作用于Namespace上，限定一个Namespace里的各类资源的使用总额。

ResourceQuota Controller流程图：

---

五、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、ListRange、ResourceQuota和Evnet等资源对象。

---

六、Endpoint Controller

Service、Endpoint、Pod的关系：

如下图所示：

Endpoints表示了一个Service对应的所有Pod副本的访问地址，而Endpoints Controller负责生成和维护所有Endpoints对象的控制器。它负责监听Service和对应的Pod副本的变化。

如果监测到Service被删除，则删除和该Service同名的Endpoints对象。
如果监测到新的Service被创建或修改，则根据该Service信息获得相关的Pod列表，然后创建或更新Service对应的Endpoints对象。
如果监测到Pod的事件，则更新它对应的Service的Endpoints对象。

kube-proxy进程获取每个Service的Endpoints，实现Service的负载均衡功能。

---

七、Endpoint Controller

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

---

总结：整理不易，如果对你有帮助，可否点赞关注一下？

更多详细内容请参考：企业级K8s集群运维实战