1. 控制器管理器概述
1.1 控制面的“大脑”：控制器管理器的角色定位
在 Kubernetes 控制面中，kube-controller-manager 是负责运行所有核心控制循环的组件。它通过 API Server 持续监听集群中各种资源（Pod、Service、Node 等）的期望状态与实际状态，一旦发现偏差，立即执行调节动作，确保集群始终向期望状态收敛。可以将其理解为控制面的“大脑”——它不直接处理用户请求，而是持续监控并修正集群内部状态。
关键角色： kube-controller-manager 是 Kubernetes 控制面中唯一一个同时管理多个独立控制循环的组件，每个控制循环（Controller）专注于一种资源或一类运维场景。
1.2 核心职责：从节点健康到工作负载调度
kube-controller-manager 内部包含数十个内置控制器，每个控制器独立运行，但共享同一个二进制进程。以下表格列出了最核心的控制器及其职责：
| 控制器名称 | 核心职责 | 监控资源 | 调节动作 |
|---|---|---|---|
| Node Controller | 节点健康检查与状态管理 | Node 对象 | 标记不可达节点、驱逐 Pod、更新节点状态 |
| Replication Controller | 确保 Pod 副本数符合期望 | ReplicaSet / Pod | 创建或删除 Pod 以匹配期望副本数 |
| Deployment Controller | 管理 Deployment 的滚动更新与回滚 | Deployment / ReplicaSet | 创建新 ReplicaSet、逐步替换旧 Pod |
| StatefulSet Controller | 管理有状态应用的 Pod 顺序与标识 | StatefulSet / Pod | 按序创建/删除 Pod、维护稳定网络标识 |
| DaemonSet Controller | 确保每个节点运行一个 Pod 副本 | DaemonSet / Node | 在新节点上创建 Pod、在节点移除时清理 |
| Job Controller | 管理一次性或批处理任务 | Job / Pod | 创建 Pod 直到任务完成、处理重试 |
| Endpoint Controller | 维护 Service 与 Pod 的映射关系 | Service / Pod / EndpointSlice | 更新 EndpointSlice 列表 |
| ServiceAccount Controller | 为命名空间自动创建默认 ServiceAccount | Namespace / ServiceAccount | 创建默认 ServiceAccount 及关联 Secret |
| Namespace Controller | 处理命名空间的生命周期 | Namespace | 删除命名空间时清理所有子资源 |
提示： 除了上述内置控制器，用户还可以通过
--controllers 启动参数选择性启用或禁用特定控制器，这在控制面资源受限或需要定制化运维策略时非常有用。
1.3 在控制面中的位置：与 API Server、Scheduler 的协作关系
kube-controller-manager 位于控制面的中间层，上游依赖 kube-apiserver 提供资源读写接口，下游与 kube-scheduler 协同完成 Pod 的调度与运行。三者之间的协作流程如下：
- 用户提交期望状态：通过 kubectl 或 API 调用创建 Deployment、Service 等资源，写入 etcd（经 API Server）。
- 控制器管理器检测偏差：控制器管理器通过 Watch 机制监听资源变化，发现 Pod 副本数不足或节点异常。
- 创建待调度 Pod：Replication Controller 或 Deployment Controller 创建新的 Pod 对象（状态为 Pending）。
- Scheduler 绑定节点：kube-scheduler 监听到未调度的 Pod，为其选择合适节点并更新 Pod 的
nodeName字段。 - 控制器管理器持续监控：Node Controller 持续检查节点心跳，Endpoint Controller 更新 Service 后端列表。
下图展示了 kube-controller-manager 在控制面中的位置及其与周边组件的交互关系：
1.4 高可用部署的必要性
在生产环境中，kube-controller-manager 必须部署为多副本高可用模式。原因如下：
- 单点故障风险：如果控制器管理器进程崩溃，所有控制循环（节点健康检查、Pod 副本管理、滚动更新等）将全部停止，集群无法自动修复偏差。
- 控制面 SLA 保障：控制面组件（API Server、Scheduler、Controller Manager）的可用性直接影响集群整体 SLA。控制器管理器的高可用配置是控制面蓝图的核心环节。
- 选举机制：多副本部署时，通过
--leader-elect参数启用领导者选举，同一时刻只有一个副本执行调节动作，避免重复操作和资源竞争。
注意： 即使控制器管理器以多副本运行，如果 API Server 或 etcd 不可用，控制器管理器也无法正常工作。高可用配置需要控制面所有组件协同。