2. Kubernetes 调度器概述：调度器在K8s架构中的位置与核心职责
Kubernetes 调度器（kube-scheduler）是控制平面中负责 Pod 与节点匹配 的核心组件。它不创建 Pod，也不运行容器，而是持续监听未绑定节点的 Pod，为其选择最合适的 Worker 节点，并将绑定决策写入 API Server。调度器的决策质量直接影响集群的资源利用率、应用性能和运维稳定性。
2.1 调度器在K8s架构中的位置
从架构视角看，kube-scheduler 位于控制平面内部，与 kube-apiserver、kube-controller-manager、etcd 并列。它通过 API Server 获取 Pod 和 Node 的实时状态，不直接与 kubelet 或容器运行时通信。
架构定位要点：
- 输入源：API Server 的 Pod 队列（spec.nodeName 为空的 Pod）
- 依赖数据：Node 状态、资源容量、标签、污点、PVC 绑定信息、存储拓扑
- 输出动作：通过 API Server 写入 Pod 的 nodeName 字段，触发 kubelet 执行
- 扩展接口：调度框架（Scheduling Framework）允许注入自定义插件
2.2 核心职责：从“待调度”到“已绑定”
调度器的本质是一个 决策循环。它从 API Server 的 Pod 队列中取出未调度的 Pod，经过过滤、打分、绑定三个阶段，最终将 Pod 分配给一个节点。整个过程必须满足约束条件（资源、亲和性、污点容忍等），同时尽量均衡集群负载。
| 阶段 | 职责 | 关键操作 | 失败处理 |
|---|---|---|---|
| 过滤（Filter） | 排除不满足硬性条件的节点 | 资源不足检查、端口冲突、污点容忍、节点选择器 | 无可用节点 → Pod 保持 Pending |
| 打分（Score） | 对剩余节点按策略排序 | 资源均衡、亲和性加分、自定义权重 | 得分相同 → 随机选择 |
| 绑定（Bind） | 将 Pod 与节点关联 | 写入 Pod 的 spec.nodeName | 写入失败 → 重试或重新调度 |
关键理解：调度器只负责“决策”，不负责“执行”。即使调度器将 Pod 绑定到某个节点，如果该节点实际资源不足或 kubelet 拒绝，Pod 仍会处于 Pending 或 CrashLoopBackOff 状态。调度器不保证 100% 的调度成功率。
2.3 调度器与周边组件的协作关系
调度器不是孤立工作的。它依赖多个组件提供输入数据，也通过 API Server 将输出传递给下游。理解这些协作关系，有助于排查调度问题和设计调度策略。
- 与 API Server：调度器通过 Watch 机制监听 Pod 和 Node 的变化，避免轮询开销。绑定操作通过 POST 请求写入 API Server。
- 与 Controller Manager：Controller Manager 管理 ReplicaSet、Deployment 等控制器，负责创建 Pod 副本。调度器只处理这些控制器生成的 Pod，不直接参与控制器逻辑。
- 与 kubelet：调度器不直接调用 kubelet。kubelet 通过 API Server 感知到 Pod 的 nodeName 与自己匹配后，才启动容器。
- 与 etcd：调度器不直接读写 etcd。所有状态都通过 API Server 中转，保证一致性和事务安全。
2.4 调度器的关键特性与设计原则
Kubernetes 调度器在设计上遵循几个关键原则，这些原则决定了它的行为模式和扩展能力：
| 特性 | 说明 | 实际影响 |
|---|---|---|
| 可插拔调度框架 | 调度器通过插件机制扩展过滤、打分、绑定等阶段 | 用户可编写自定义调度策略，无需修改核心代码 |
| 无状态设计 | 调度器不持久化任何状态，所有数据从 API Server 获取 | 支持多副本部署，任一调度器故障可被其他副本接管 |
| 乐观并发 | 调度器假设资源充足，绑定失败后重试或重新调度 | 减少锁竞争，提高调度吞吐量 |
| 异步绑定 | 调度器发出绑定请求后不等待 kubelet 确认 | 调度器不会因 kubelet 响应慢而阻塞 |
常见误解：调度器不是负载均衡器。它只在 Pod 创建时做一次调度决策，不会在 Pod 运行后重新平衡。如果集群出现资源碎片或节点过载，需要依赖 Descheduler 或手动干预来重新调度。
2.5 调度器的高可用与扩展性
在生产环境中，kube-scheduler 通常以多副本方式部署，并通过 leader election 机制保证同一时刻只有一个调度器执行绑定操作。这种设计既保证了高可用，又避免了调度冲突。
- Leader Election：多个调度器实例竞争同一个 Endpoint（或 Lease），只有 leader 执行绑定，其他实例处于热备状态。
- 调度队列：每个调度器实例维护独立的 Pod 队列，但只有 leader 的绑定操作会被 API Server 接受。
- 性能指标：单调度器实例通常可以支撑每秒 100-300 个 Pod 的调度（取决于集群规模和插件复杂度）。
调度器性能关键指标：
- 调度延迟：从 Pod 进入队列到绑定完成的时间，通常应 < 1s
- 调度吞吐量：每秒成功调度的 Pod 数量
- 绑定失败率：绑定请求被 API Server 拒绝的比例，通常应 < 0.1%
- Pending Pod 数量：长时间未调度的 Pod 数，反映调度器健康度