Controller Manager 详解：Kubernetes 集群的自动化大脑

Controller Manager 是 Kubernetes 控制平面里最容易被忽略、但又极其关键的组件之一。它不直接帮你跑业务容器，也不负责调度节点，但它负责一件更本质的事：持续把“集群实际状态”拉回到“用户期望状态”。

它到底负责什么

Kubernetes 为什么能做到“声明式管理”？核心原因之一，就是控制器在不停地做协调。

你声明：

• Deployment 要 3 个副本
• DaemonSet 要每个节点都跑一个 Pod
• Node 掉线后要自动处理

而 Controller Manager 就是在后台不停盯着这些目标，发现偏差就纠正。

核心作用

它不是一个控制器，而是一组控制器

Controller Manager 并不是单一逻辑，而是一组控制器的集合。每个控制器都只关注一种资源或一类问题。

常见控制器包括：

• Deployment Controller
• ReplicaSet Controller
• StatefulSet Controller
• DaemonSet Controller
• Job Controller
• Endpoints Controller
• Namespace Controller
• Node Controller

可以把它理解成一个控制器运行平台，而不是一个“万能大模块”。

几个最关键的控制器

Deployment Controller

它负责盯住 Deployment，确保副本数和更新策略真正落地。

比如你把副本数从 3 改到 5，或者换了镜像版本，它就会触发对应的滚动更新或副本调整。

ReplicaSet Controller

它更贴近 Pod 数量本身，确保当前副本数和 spec.replicas 一致。

如果某个 Pod 挂掉了，ReplicaSet Controller 会发现实际数量少了，然后补回来。

StatefulSet Controller

这个控制器主要面向有状态应用，比如数据库、消息队列。

它会确保：

• Pod 名称和编号稳定
• 存储卷绑定关系稳定
• 启停顺序可控

DaemonSet Controller

它保证某个 Pod 在所有节点，或者指定节点上都存在一份。

这类模式常见于：

• 日志收集
• 节点监控
• 安全代理

Endpoints Controller

它负责把 Service 和后端 Pod 关联起来。

Service 之所以能把流量打到正确 Pod 上，不是 Service 自己“会找”，而是 Endpoints Controller 在根据标签和 Pod 状态维护后端列表。

Node Controller

它主要负责监控节点健康状态。

典型行为包括：

• 节点掉线后标记 NotReady
• 长时间失联后触发 Pod 驱逐逻辑

它是怎么工作的

控制器最核心的机制，就是大家常说的 Reconciliation Loop，也就是“协调循环”。

可以粗暴理解成下面这个逻辑：

for {
    desiredState := GetDesiredState()
    currentState := GetCurrentState()
    if currentState != desiredState {
        Reconcile()
    }
    sleep(syncPeriod)
}

这套模式决定了 Kubernetes 的很多行为不是“一次性执行”，而是“持续对齐”。

以 Deployment 为例看一遍完整流程

假设你提交了一个 Deployment，要求运行 3 个 Pod。

后面大致会发生这些事：

1. API Server 接收 Deployment 并写入 etcd
2. Deployment Controller 发现新对象
3. 它创建对应的 ReplicaSet
4. ReplicaSet Controller 发现当前 Pod 数量不够
5. 它调用 API Server 创建 Pod
6. Scheduler 把 Pod 调度到具体节点
7. kubelet 在节点上真正拉起容器
8. 后续如果 Pod 挂掉，控制器会再次补齐

所以从集群角度看，用户只是声明“要 3 个”，真正把这件事持续做成的是控制器。

常见排查思路

如果控制器行为和预期不一致，通常从下面几个方向查：

看日志

kubectl logs -n kube-system kube-controller-manager-<pod-id>

如果是静态 Pod 部署，也可能需要直接在节点上查看：

journalctl -u kube-controller-manager -f

看权限和通信

如果它连不上 API Server，或者 RBAC 权限不足，很多控制器都会表现成“资源没反应”。

看资源对象本身是否冲突

比如：

• Deployment 选择器写错
• Service selector 匹配了错误 Pod
• ReplicaSet selector 与现有资源冲突

这类问题表面看像“控制器没工作”，本质上往往是对象定义本身就不合理。

总结

如果要用一句话总结 Controller Manager，最准确的说法其实不是“控制器集合”，而是：

它是 Kubernetes 把声明变成现实的执行引擎。

没有它，Kubernetes 仍然能存储资源定义；但只有它持续运行，集群才会真正表现出自愈、扩缩、副本修复和状态收敛这些能力。