scheduler 与 controller-manager
控制面的「决策者」与「执行者」
底座认知 · 第 06 篇
调度流程与控制器模式：状态如何被持续拉回期望
目 录
一、两个组件的分工
二、kube-scheduler：为新 Pod 选节点
2.1 调度流程
2.2 调度约束
三、kube-controller-manager：状态收敛的引擎
3.1 控制器模式
3.2 常见内置控制器
四、leader 选举与高可用
五、排障要点
一、两个组件的分工
scheduler（调度器）与 controller-manager（控制器管理器）同属控制面，但分工明确：调度器决定「新 Pod 放到哪个节点」，控制器管理器负责「持续把集群状态拉回期望状态」。
二、kube-scheduler：为新 Pod 选节点
2.1 调度流程
调度器监听 apiserver 中新创建的、尚未调度的 Pod，通过两阶段为其选定节点：
- Filter 预选：过滤掉不满足条件的节点（资源不足、taint 不匹配、不满足亲和性等）
- Score 优选：在候选节点上打分（资源均衡、亲和性、负载等），选最高分
- Bind 绑定：将 Pod 绑定到选定节点，写入 etcd
2.2 调度约束
- nodeSelector / nodeAffinity：按节点标签选择
- podAffinity / podAntiAffinity：按与其他 Pod 的关系选择
- Taint 与 Toleration：节点打污点，只有容忍的 Pod 才能调度上去
排障常看：Pod 长时间 Pending，多半是 Filter 阶段没有可用节点，可用 kubectl describe pod 查看调度事件。
三、kube-controller-manager：状态收敛的引擎
3.1 控制器模式
K8s 的核心哲学是「声明式 + 控制器循环」：用户声明期望状态，控制器持续对比「期望」与「当前」，并采取行动使二者收敛。
控制器模式（Reconcile 循环）：读取期望状态 → 读取当前状态 → 对比差异 → 执行操作使其收敛 → 循环往复。
3.2 常见内置控制器
控制器 | 职责 |
ReplicaSet / Deployment | 维持副本数，滚动更新与回滚 |
StatefulSet | 有状态应用的有序部署与稳定标识 |
DaemonSet | 确保每个（部分）节点运行一个 Pod |
Node | 监控节点健康，标记 NotReady |
Endpoint / EndpointSlice | 维护 Service 背后的 Pod 端点 |
Namespace / GarbageCollector | 资源清理与级联删除 |
四、leader 选举与高可用
生产环境 scheduler 与 controller-manager 都会多副本部署，但同一时刻只允许一个实例真正工作，通过 leader 选举（基于 etcd lease）保证。
- leader 负责实际执行，备用实例处于待命
- leader 故障时自动切换到备用实例，实现高可用
- 可在日志中看到 elected as leader 字样
五、排障要点
- Pod Pending：查看调度事件，定位是资源不足还是调度约束
- 副本数不对：检查对应控制器的 Reconcile 是否正常，controller-manager 是否健康
- 新增节点不参与调度：检查节点状态与 taint
下一篇进入数据面，看 kubelet 与 kube-proxy 如何在节点上真正「跑起来」。
