1. K8s 调度器概述
1.1 调度器在 K8s 架构中的位置
Kubernetes 调度器（kube-scheduler）是控制平面的核心组件之一，负责将待调度的 Pod 绑定到最合适的 Node 上。在 K8s 整体架构中，调度器位于 API Server 与 Node 之间，扮演“资源分配决策者”的角色。
关键定位： 调度器不直接管理 Pod 生命周期，也不运行容器；它仅做出“Pod → Node”的绑定决策，并将结果写入 API Server 的 etcd 中。
调度器在 K8s 控制平面中的位置关系如下表所示：
| 组件 | 角色 | 与调度器的关系 |
|---|---|---|
| API Server | 统一入口，存储集群状态 | 调度器通过 API Server 监听未调度的 Pod 和 Node 信息 |
| etcd | 分布式键值存储 | 调度结果（Pod 与 Node 的绑定关系）持久化到 etcd |
| Controller Manager | 维护集群期望状态 | 调度器与控制器协同工作，控制器创建 Pod 后由调度器分配 Node |
| kubelet | Node 代理，管理容器 | 调度器绑定 Pod 后，kubelet 负责在对应 Node 上启动 Pod |
架构要点： 调度器通过 API Server 的 Watch 机制监听
Pod.spec.nodeName 为空的 Pod，然后执行调度算法，最终将 Pod 与 Node 的绑定关系写入 API Server。整个过程是异步的、事件驱动的。
1.2 调度器工作原理
K8s 调度器的工作流程可以概括为“两阶段三步骤”：过滤（Predicates）→ 打分（Priorities）→ 绑定（Bind）。调度器为每个待调度的 Pod 执行以下步骤：
- 过滤阶段（Filtering）： 遍历所有 Node，排除不满足 Pod 调度约束的节点。例如：资源不足、节点污点不匹配、端口冲突、节点选择器不满足等。
- 打分阶段（Scoring）： 对通过过滤的 Node 进行优先级评分，计算每个节点的综合得分。评分策略包括：资源利用率均衡、镜像本地性、节点亲和性等。
- 绑定阶段（Binding）： 选择得分最高的 Node，将 Pod 绑定到该节点上。如果多个 Node 得分相同，则随机选择一个。
性能关键点： 调度器默认使用“调度队列 + 调度周期”的并发模型。每个调度周期独立处理一个 Pod，调度周期之间互不阻塞。默认并发度为 1（即一次只调度一个 Pod），可通过
--kube-api-qps 和 --kube-api-burst 参数调整。
常见误区： 过滤阶段是“硬约束”，不满足条件的 Node 会被直接排除；打分阶段是“软约束”，得分低的 Node 仍然可能被选中（如果其他 Node 都不可用）。不要将打分策略理解为必须满足的条件。
1.3 调度器核心组件
K8s 调度器内部由多个模块化组件构成，每个组件负责调度流程中的一个特定环节。核心组件包括：
| 组件名称 | 职责 | 关键数据结构/行为 |
|---|---|---|
| Scheduling Queue | 管理待调度的 Pod 队列，支持优先级排序、重试、回退 | ActiveQ / BackoffQ / UnschedulableQ |
| Framework | 调度框架，定义扩展点（Extension Points）并执行插件 | PreFilter / Filter / PostFilter / PreScore / Score / NormalizeScore / Reserve / Permit / PreBind / Bind / PostBind |
| Plugin | 实现具体调度策略的插件，可自定义扩展 | NodeResourcesFit / NodeName / TaintToleration / InterPodAffinity 等 |
| Cache | 缓存集群中 Node 和 Pod 的最新状态，避免频繁访问 API Server | NodeInfo / PodInfo / AssumedPod |
| Binder | 执行 Pod 与 Node 的绑定操作，写入 API Server | Binding 对象 / 异步写入 |
调度框架（Scheduling Framework） 是 K8s 1.15+ 引入的插件化调度架构。它将调度流程拆分为多个扩展点，每个扩展点可以注册多个插件。调度器按照固定顺序执行这些扩展点，插件可以在扩展点处注入自定义逻辑。这种设计使得调度策略的定制和扩展变得非常灵活。
调度框架的核心扩展点执行顺序如下：
QueueSort → PreFilter → Filter → PostFilter → PreScore → Score → NormalizeScore → Reserve → Permit → PreBind → Bind → PostBind
性能优化切入点： 调度器性能瓶颈通常出现在 Filter 和 Score 阶段。当集群规模较大（数千 Node）时，每个 Pod 的调度周期需要遍历所有 Node，计算量呈线性增长。优化方向包括：缓存预热、并行过滤、打分结果缓存、以及使用更高效的调度算法（如基于拓扑的调度）。