概述
智能系统和自动系统通常会通过一个操作系统来不断修正系统的工作状态。在k8s中，每个Controller都是这样一个操作系统，它们通过API Server提供的（List-Watch）接口实时监控集群中特定资源的状态变化，当发生各种故障导致某资源对象的状态发生变化时，Controller会尝试将其状态调整为期望状态。
Kubernetes 中的 Controller Manager 是集群管理中的核心组件之一，它是一个聚合了多个控制器功能的进程，运行在 Master 节点上，负责维护集群的期望状态（desired state）与实际状态（current state）的一致性。
Controller Manager内部包含Replication Controller、Node Controller、ResourceQuota Controller、Namespace Controller、ServiceAccount Controller、Token Controller、Service Controller及Endpoint Controoler八种。而Controller Manager正式这些Controller的核心管理者。
Replication Controller
Replication Controller 核心作用确保任何时候集群中的RC关联的Pod副本数量都保持预设值，多退少补原则。需要注意的是，只有当重启策略是Always时，才起作用。
最好不要越过RC直接创建Pod，因为RC会管理Pod的副本，这样可以提高系统的容灾能力。
- 确保在当前集群中有且仅有N个Pod实例，N是在RC中定义的Pod副本数量。
- 调整RC的
spec.replicas属性值来实现系统扩缩容。 - 改变RC中的Pod模版（镜像版本）来实现系统的滚动升级。
Replication Controller使用场景：
- 重新调度
- 弹性伸缩
- 滚动更新
Node Controller
Kubelet 进程在启动时通过API Server注册自身的节点信息，并定时向API Server汇报状态，API Server收到这些信息后会通过到ETCD中。其信息包括节点健康状况、节点资源、节点名称、节点地址信息、操作系统版本、docker版本、kubelet版本等。
Node Controller通过API Server实时获取Node的相关信息，实现管理和监控集群中的各个Node的相关控制功能。
初始化与启动：
Node Controller是 KubernetesController Manager中的一部分，在Controller Manager启动时会被初始化和启动。Node Controller 初始化时，会根据给定的配置构建自身的大结构体，完成必要的参数配置。
监听节点状态：
Node Controller通过 API Server 获取集群中所有 Node（节点）的实时状态信息。- 为
nodeInformer配置回调函数（AddFunc, UpdateFunc, DeleteFunc），当有节点新增、更新或删除时，Node Controller能够得到通知。
节点心跳监测：
Node Controller通过检查节点发送的心跳（通常是通过节点定期更新其 Lease 对象实现）来确定节点是否正常工作。- 如果节点长时间未发送心跳，
Node Controller将判断节点可能已宕机或失去联系，并采取相应措施。
节点健康状态处理：
- 当节点未响应或报告为非健康状态时，
Node Controller会先尝试标记节点为不可调度（Taint节点，防止新 Pod 被调度到该节点上）。 - 若节点长时间未恢复，
Node Controller会进一步操作，如驱逐（Evict）节点上运行的所有 Pods，让它们在其他健康节点上重新调度。
节点清理：
- 对于长时间未响应且确认无法恢复的节点，
Node Controller可能会从集群中彻底删除该节点记录，以便释放相关资源和名称空间。
节点配置更新同步：
- 当节点的配置发生变化时，如节点容量（
capacity）更新或标签（labels）变化，Node Controller会确保集群中的相关信息得到及时更新和同步。
与其它控制器协作：
Node Controller还与其他控制器交互，例如DaemonSet Controller，确保守护进程集在每个节点上的正确部署和管理。
ResourceQuota Controller
资源配额管理确保了指定的资源对象在任何时候都不会超量占用系统物理资源，避免了由于某些业务进程的设计和实现的缺陷导致整个系统瘫痪。
目前k8s支持如下三个层次的资源配额
- 容器级别
- Pod级别
- Namespace级别
- Pod数量
- Replication Controller数量
- Service数量
- ResourceQuota数量
- Secret数量
- PV数量
其实现方式通过 Admission Control（准入控制）来控制的，当前提供了两种方式的配额约束
LimitRanger：作用于Pod和Container。ResourceQuota：作用于Namespace。
如果Pod定义中声明了LimitRanger，则用户通过API Server请求创建或者修改资源时，Admission Control会计算当前配合的使用情况，如果不符合条件则创建失败。
对应定义了ResourceQuota的Namespace，ResourceQuota Controller组件会定义统计和生成该Namespace下的所有资源使用量，将统计结果写入ETCD。随后统计数据被Admission Control使用，以确保当前Namespace下的资源配额总量不会超过ResourceQuota中的限定值。
Namespace Controller
API Server可以创建新的Namespace并将其保存到ETCD中，Namespace Controller定时通过API Server读取这些信息。如果Namespace被API标记为删除，则将该Namespace状态设置成Terminating并保存到ETCD中。同时，Namespace Controller删除其下的所有资源，最后对Namespace执行finalize操作，删除spec.finalizers 域中的信息。
Service Controller和Endpoints Controller
Service、Endpoints与Pod关系，如下图：
Endpoints表示一个Service对应的所有Pod副本的访问地址，Endpoints Controller负责生成和维护所有Endpoints对象的控制器。它负责监听Service和对应的Pod副本变化，如果监听到Service被删除，则删除和该Service同名的Endpoints对象。如果检测到被创建或则修改，则根据该Service信息获得相关的Pod列表，然后创建或者更新Endpoints对象。更新或者身处Pod，同理。
Endpoints对象在哪里被使用呢？答案是Node上的kube-proxy进程，它获取每个Endpoints，实现Service的负载均衡。
结语
Kubernetes Controller 在整个集群管理中扮演着至关重要的角色，它们是实现自动化运维和自我修复能力的关键所在。从经典的Replication Controller（已逐渐被 ReplicaSet 和 Deployment 所替代）到更复杂的StatefulSet、Job以及各种自定义控制器（Custom Controllers），每种控制器都专注于特定类型的资源管理和生命周期管理。例如，Endpoints Controller 负责同步Service与Pod之间的端点关系，而Deployment Controller 则确保应用程序能够按照预设策略进行滚动更新、回滚等操作。
此外，随着Kubernetes生态系统的扩展，通过CRD（CustomResourceDefinition）创建自定义资源类型成为常态，开发者可以基于client-go库构建自己的控制器来满足特定业务需求，这些自定义控制器同样遵循标准的Kubernetes控制器模式，并通过选举机制确保集群中只有一个活动实例来避免冲突和重复工作。
总之，Kubernetes Controller是维持集群稳定性、可靠性和可扩展性的基石，在理解和掌握Kubernetes架构及其内部原理时，深入剖析Controller的工作机制是十分必要的。