解剖K8s控制平面（下）：Scheduler与Controller Manager如何让集群“智能运行“？

大家好，我是刘叨叨，一个致力于让碎片化技术系统性的运维人。

为什么需要这两个"智能助理"？

想象一下：公司新招聘了3名员工（Pod），现在需要：

如果没有这两个角色，新员工可能都挤在同一个工位，或者上班不知道干啥。Scheduler和Controller Manager就是K8s集群的人事经理+部门主管，让每个Pod都在正确的地方做正确的事。

Scheduler：不只是"随机分配"

核心任务：为Pod找到"最佳归宿"

调度过程三步骤：

🔍 过滤（Filtering） → 排除不合适的节点
📊 评分（Scoring） → 为合适节点打分
🏆 选择（Selecting） → 选择最高分节点

过滤阶段：硬性条件检查

# Pod可能要求的条件：
spec:
# 1. 资源需求
resources:
requests:
cpu: "500m" # 需要0.5核CPU
memory: "512Mi" # 需要512MB内存
# 2. 节点选择器
nodeSelector:
gpu: "nvidia" # 必须有GPU标签
# 3. 节点亲和性
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
– matchExpressions:
– key: zone
operator: In
values: [zoneA, zoneB] # 必须在zoneA或zoneB

实际调度示例

# 场景：部署一个需要GPU的AI应用
apiVersion: v1
kind: Pod
metadata:
name: ai-training
spec:
containers:
– name: trainer
image: tensorflow:latest
resources:
requests:
cpu: "2"
memory: "8Gi"
nvidia.com/gpu: "1" # 请求GPU资源
nodeSelector:
accelerator: "gpu" # 必须是有GPU的节点

调度决策过程：

1. 过滤：
node-01（无GPU标签） ❌ 排除
node-02（有GPU，但只有1核CPU） ❌ 排除
node-03（有GPU，4核CPU，16GB内存） ✅ 通过
2. 评分：
node-03：资源充足，标签匹配 → 得分100
3. 绑定：
将Pod绑定到node-03，更新etcd

Controller Manager：集群的"自动纠错系统"

核心思想：声明式状态管理

工作模式：

期望状态（etcd中） ← 对比 → 实际状态（集群中）
↓ ↓
声明式配置 当前运行状态
↓ ↓
如有差异 → 执行操作 → 达到一致

主要控制器及其职责

1. Deployment Controller

管理：Deployment → ReplicaSet → Pod
职责：确保指定数量的Pod副本运行
场景：滚动更新、回滚、扩缩容

2. ReplicaSet Controller

管理：ReplicaSet → Pod
职责：确保有正确数量的Pod副本
关键：通过标签选择器管理Pod

3. Node Controller

职责：
├── 监控节点状态（通过kubelet心跳）
├── 标记不可用节点为NotReady
└── 驱逐节点上的Pod（若需要）

4. Service Controller

职责：创建/更新/删除负载均衡器
云厂商集成：AWS ELB、GCP Load Balancer等

5. Endpoint Controller

职责：维护Service与Pod的映射关系
数据：Endpoint对象（哪些Pod属于哪个Service）

控制器协作流程示例

# 用户创建一个Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 3 # 期望：3个副本
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
– name: nginx
image: nginx:1.20

控制器的接力赛：

🏁 起点：用户创建Deployment
↓
🎯 Deployment Controller监听到新对象
↓
📝 创建对应的ReplicaSet（期望3个副本）
↓
🎯 ReplicaSet Controller监听到新对象
↓
📝 发现当前Pod数量：0，期望：3 → 创建3个Pod定义
↓
🎯 Scheduler监听到未调度的Pod
↓
📍 为每个Pod选择节点，更新nodeName字段
↓
🎯 各节点的kubelet监听到分配给自己的Pod
↓
🚀 拉取镜像，启动容器
↓
📊 上报Pod状态（Running）到API Server
↓
🔄 各Controller持续监控，确保状态一致

互动讨论

你在实际工作中遇到过哪些调度或控制器问题？分享你的经验，让我们一起探讨解决方案！

整个控制平面系列到此结束。从API Server的"接待"到etcd的"记忆"，再到Scheduler的"安排"和Controller Manager的"监督"，这四个组件协同工作，构成了K8s集群的智能大脑。

下期我们将进入数据平面，看看kubelet与kube-proxy如何在工作节点上执行控制平面的决策，让理论真正落地运行。

搜索关注【刘叨叨趣味运维】公众号，用有趣的方式，啃下最硬核的技术。咱们下期见！