一、Controller Manager简介

Controller Manager作为集群内部的管理控制中心，负责集群内的Node、Pod、Endpoint、Namespace、ServiceAccount、ResourceQuota的管理，

每个Controller通过API Server提供的接口实时监控整个集群的每个资源对象的当前状态，当发生各种故障导致系统状态发生变化时，会尝试将系统状态修复到“期望状态”。例如：当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。

几乎每种特定资源都有特定的Controller维护管理以保持预期状态，而Controller Manager的职责便是把所有的Controller聚合起来，提供基础设施降低 Controller 的实现复杂度，启动和维持 Controller 的正常运行。

从比较高维度的视角看，Controller Manager 主要提供了一个分发事件的能力，而不同的 Controller 只需要注册对应的 Handler 来等待接收和处理事件。

 

二、Controller Manager含有的controller种类

Controller Manager聚合的种类较多，包含：

Replication Controller

Node Controller

CronJob Controller

Daemon Controller

Deployment Controller

Endpoint Controller

Garbage Collector

Namespace Controller

Job Controller

Pod AutoScaler

RelicaSet

Service Controller

ServiceAccount Controller

StatefulSet Controller

Volume Controller

Resource quota Controller

 

三、需要选主

K8s中的control-plane包括了apiserver、controller-manager、scheduler、etcd，当搭建高可用集群时就会涉及到部分组件的选主问题。etcd是整个集群所有状态信息的存储，涉及数据的读写和多个etcd之间数据的同步，对数据的一致性要求严格，所以使用较复杂的raft算法来选择用于提交数据的主节点。而apiserver作为集群入口，本身是无状态的web服务器，多个apiserver服务之间直接负载请求并不需要做选主。Controller-Manager和Scheduler作为任务类型的组件，比如controller-manager内置的k8s各种资源对象的控制器实时的watch apiserver获取对象最新的变化事件做期望状态和实际状态调整，调度器watch未绑定节点的pod做节点选择，显然多个这些任务同时工作是完全没有必要的，所以controller-manager和scheduler也是需要选主的，但是选主逻辑和etcd不一样的，这里只需要保证从多个controller-manager和scheduler之间选出一个进入工作状态即可，而无需考虑它们之间的数据一致和同步。他们是基于etcd集群上的分布式锁实现领导者选举机制，抢先获取锁的实例被称为leader.

 

四、一些特性

4.1 Replication Controller

只有当Pod的重启策略是Always的时候（RestartPolicy=Always），副本控制器才会管理该Pod的操作（创建、销毁、重启等）。

RC中的Pod模板就像一个模具，模具制造出来的东西一旦离开模具，它们之间就再没关系了。一旦Pod被创建，无论模板如何变化，也不会影响到已经创建的Pod。

Pod可以通过修改label来脱离RC的管控，该方法可以用于将Pod从集群中迁移，数据修复等调试。

删除一个RC不会影响它所创建的Pod，如果要删除Pod需要将RC的副本数属性设置为0。

不要越过RC创建Pod，因为RC可以实现自动化控制Pod，提高容灾能力。

 

4.2 ResourceQuota Controller

k8s配额管理是通过Admission Control（准入控制）来控制的；

Admission Control提供两种配额约束方式：LimitRanger和ResourceQuota；

LimitRanger作用于Pod和Container；

ResourceQuota作用于Namespace上，限定一个Namespace里的各类资源的使用总额。

 

4.3 Endpoint Controller

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

如果监测到Service被删除，则删除和该Service同名的Endpoints对象；

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

如果监测到Pod的事件，则更新它对应的Service的Endpoints对象。

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

 

 

参考：https://blog.csdn.net/huwh_/article/details/75675761（几种常用的控制器）