📚 课程目录第3章 etcd性能关键指标

3. K8s调度器架构与延迟来源：分析kube-scheduler的调度流程（预选、优选、绑定），识别跨集群场景下调度延迟的主要来源（网络、etcd读取、API Server负载）

在跨集群调度场景中，kube-scheduler 是决定 Pod 能否快速分配到目标集群的核心组件。理解其内部架构与延迟来源，是优化跨集群调度延迟的第一步。本章将深入分析调度器的三阶段流程（预选、优选、绑定），并逐一拆解跨集群场景下的主要延迟瓶颈。

kube-scheduler 采用 “过滤 → 打分 → 绑定” 的流水线架构。每个 Pod 的调度周期由多个串行与并行阶段组成。下图展示了调度器内部的核心组件与数据流：

预选阶段的目标是快速过滤掉不满足 Pod 运行条件的节点。调度器并行执行多个过滤插件，每个插件检查一个维度。常见的过滤插件包括：

在跨集群场景中，预选阶段需要从 API Server 获取所有候选集群的节点状态。如果集群数量多、节点规模大，etcd 读取延迟和 API Server 响应时间会显著增加预选耗时。

通过预选的节点进入优选阶段，调度器对每个节点进行多维度打分，最终选择得分最高的节点。常用打分插件包括：

优选阶段的计算量通常比预选更大，因为它需要对每个候选节点执行加权求和。在跨集群场景中，如果打分插件需要跨集群查询数据（如镜像缓存状态），网络延迟会进一步放大优选耗时。

绑定阶段是调度流程的最后一步。调度器通过 API Server 创建一个 Binding 对象，将 Pod 与目标节点绑定。绑定操作本身是一个 POST 请求，写入 etcd 后触发 kubelet 拉取 Pod 并启动容器。

在跨集群场景中，绑定阶段可能涉及跨集群 API Server 通信。如果目标集群的 API Server 负载高或网络延迟大，绑定请求的响应时间会直接拖慢整个调度周期。

跨集群调度延迟并非单一因素导致，而是多个环节叠加的结果。下表总结了主要延迟来源及其影响程度：

延迟来源	影响阶段	延迟特征	典型延迟范围	优化优先级
网络延迟	预选、优选、绑定	跨集群通信 RTT，带宽限制	10ms ~ 500ms	高
etcd 读取延迟	预选、优选	节点/集群状态查询，大对象反序列化	5ms ~ 200ms	高
API Server 负载	预选、优选、绑定	高并发请求排队，限流	20ms ~ 1s+	高
插件执行耗时	预选、优选	过滤/打分逻辑复杂度	1ms ~ 50ms	中
调度队列等待	调度前	Pod 排队，优先级抢占	10ms ~ 100ms	中

关键洞察：在跨集群调度中，网络延迟和 etcd 读取延迟 是占比最高的两个因素，通常占总调度延迟的 60%~80%。优化这两个环节是降低跨集群调度延迟的核心突破口。

跨集群调度场景下，调度器通常部署在中心集群，需要与多个边缘集群的 API Server 通信。网络延迟主要来自：

调度器在预选和优选阶段需要频繁读取 etcd 中的节点状态、Pod 状态、集群配置等数据。etcd 读取延迟的主要来源包括：

API Server 是调度器与 etcd 之间的唯一桥梁。当多个调度器或控制器同时发起大量请求时，API Server 可能成为瓶颈：

请求排队：API Server 的 HTTP 处理线程池有限，请求过多时排队等待。
限流机制：API Server 的 --max-requests-inflight 和 --max-mutating-requests-inflight 参数限制并发请求数。
Watch 连接：大量 Watch 连接占用 API Server 内存和 CPU。
List 操作：全量 List 节点或 Pod 时，API Server 需要从 etcd 读取大量数据并序列化返回。

为了更直观地理解延迟分布，以下是一个典型的跨集群调度延迟量化示例（基于 3 个集群、每个集群 50 个节点的场景）：

调度阶段	平均耗时	P99 耗时	主要延迟来源
预选阶段	120ms	450ms	etcd 读取（节点状态）、网络延迟（跨集群查询）
优选阶段	80ms	300ms	etcd 读取（镜像缓存）、API Server 负载
绑定阶段	50ms	200ms	网络延迟（跨集群 API Server 写入）
总调度延迟	250ms	950ms	—

优化提示：从量化数据可以看出，预选阶段是延迟占比最高的环节（约 48%）。优化预选阶段的 etcd 读取和网络通信，能带来最显著的延迟降低效果。后续章节将深入讲解如何通过缓存、预取、异步化等手段优化这些瓶颈。