2. 单点故障问题
在 Kubernetes 控制面中，kube-controller-manager 负责运行集群内几乎所有核心控制器（如节点控制器、副本控制器、端点控制器、服务账户控制器等）。当采用单实例部署时，该组件成为整个集群控制面的单点故障（SPOF）。一旦进程崩溃、节点宕机或网络隔离，所有控制器循环将同时中断，集群的自我修复与状态调节能力完全丧失。
核心风险：单控制器管理器架构下，故障影响范围是全局性的——不是某个控制器不可用，而是全部控制器同时失效。这意味着集群既无法创建新 Pod，也无法恢复已崩溃的工作负载，甚至节点心跳检测也会停止。
故障场景分析
以下表格归纳了单控制器管理器架构下最常见的三类故障场景及其触发条件：
| 故障类型 | 触发条件 | 典型表现 |
|---|---|---|
| 进程级故障 | 控制器管理器进程因 OOM、panic、死锁或配置错误而退出 | kube-controller-manager Pod 状态变为 CrashLoopBackOff；集群停止调节 |
| 节点级故障 | 运行控制器管理器的控制面节点宕机、重启或网络中断 | API Server 可达但控制器管理器无响应；节点心跳超时但无驱逐动作 |
| 网络分区故障 | 控制器管理器所在节点与 API Server 之间网络隔离 | 控制器管理器无法 watch/list API 资源；Leader 选举（单实例无选举）直接中断 |
关键观察：在单实例架构中，进程级故障与节点级故障的恢复时间完全取决于运维手动介入速度。没有自动故障转移机制，MTTR（平均修复时间）可能从分钟级延长到小时级。
对集群的影响
单控制器管理器失效时，集群控制面的调节回路（Reconciliation Loop）全面停止。具体影响按严重程度排列如下：
- 工作负载无法自愈——ReplicaSet 控制器停止工作，Pod 崩溃后不会被重新创建；Deployment 滚动更新或回滚操作无法进行。
- 节点状态冻结——Node Lifecycle 控制器不再检测节点心跳，
node.kubernetes.io/unreachable污点不会被自动添加，故障节点上的 Pod 不会被驱逐。 - 服务端点失效——EndpointSlice 控制器停止更新 Service 后端端点列表，导致流量可能被路由到已终止的 Pod。
- 资源配额与安全策略失效——ResourceQuota 控制器、ServiceAccount 控制器、 控制器均停止调节，新创建的 Pod 可能绕过配额限制或缺少服务账户凭证。
- 集群扩展能力丧失——Cluster Autoscaler 依赖控制器管理器中的节点状态信息，一旦控制器管理器不可用，自动扩缩容决策无法触发。
单点故障的根因总结
单控制器管理器架构之所以成为风险，根源在于缺乏冗余与故障转移机制：
- 无 Leader 选举——单实例模式下，没有备用实例可以接管工作。
- 无健康检查隔离——即使 API Server 健康，控制器管理器内部的单个 goroutine 死锁也可能导致整个进程无响应。
- 无状态持久化——控制器管理器本身不持久化状态，但中断期间丢失的事件和调节周期无法自动回放，导致集群状态与实际期望产生偏差。