1. 课程导学与前置知识

1.1 Kubernetes 调度器架构概述

Kubernetes 调度器（kube-scheduler）是控制平面的核心组件之一，负责将待调度的 Pod 绑定到最合适的 Node 上。调度过程并非一次性决策，而是通过一系列阶段（Phase）和扩展点（Extension Point）组合而成，形成可插拔的调度管道。

调度器内部维护一个调度队列（Scheduling Queue），所有未被调度的 Pod 按优先级入队。调度周期分为两个主要阶段：

• Scheduling Cycle（调度周期）：选择一个 Node 给 Pod，是同步操作。
• Binding Cycle（绑定周期）：将调度决策持久化到 API Server，是异步操作。

下图展示了调度器内部的核心组件与调度流程：

1.2 Scheduler Framework 扩展点详解

Kubernetes 从 v1.19 开始将 Scheduler Framework 作为默认调度框架。框架定义了一组清晰的扩展点（Extension Points），每个扩展点对应调度周期或绑定周期中的一个特定阶段。插件可以注册到一个或多个扩展点，从而影响调度决策。

下表列出了主要的扩展点及其作用：

1.3 网络拓扑感知调度概念

网络拓扑感知调度（Network Topology Aware Scheduling）是指调度器在做出调度决策时，不仅考虑节点的 CPU、内存等传统资源，还考虑节点之间的网络拓扑结构——包括物理机架、交换机层级、可用区（Zone）、区域（Region）等网络距离因素。

核心目标：将相互通信频繁的 Pod 调度到网络距离最近的节点上，从而降低跨节点通信延迟、减少网络带宽消耗、提升应用整体性能。

常见的网络拓扑层次结构如下：

• 同一节点（Node）：Pod 间通过本地回环或容器网络通信，延迟最低（通常 < 0.1ms）。
• 同一机架（Rack）：通过架顶交换机（ToR）通信，延迟较低（通常 0.1–0.5ms）。
• 同一可用区（Zone）：通过区域汇聚交换机通信，延迟中等（通常 0.5–2ms）。
• 跨可用区（Cross-Zone）：通过核心路由器或广域网通信，延迟最高（通常 2–10ms+）。

下图展示了典型的集群网络拓扑层次与调度目标：

1.4 为什么需要网络拓扑感知调度

在云原生场景下，微服务架构中的服务间调用非常频繁。如果调度器不考虑网络拓扑，可能出现以下问题：

• 跨可用区流量激增：大量 Pod 分散在不同 Zone，导致跨 Zone 网络带宽被占满，延迟上升。
• 带宽成本增加：云厂商通常对跨可用区流量收费，不合理调度会增加运营成本。
• 应用性能抖动：关键路径上的服务因网络延迟变长而响应超时。
• 资源碎片化：节点资源利用率不均，但拓扑约束未被考虑，导致局部热点。

网络拓扑感知调度通过以下方式解决上述问题：

1.5 课程学习路径与前置要求

本课程将带领你从零开始，完整实现一个生产级别的网络拓扑感知调度插件。课程分为四个阶段：

1. 基础篇（第 1–5 章）：调度器架构、Framework 扩展点、开发环境搭建、插件注册与配置。
2. 核心篇（第 6–15 章）：拓扑信息采集、节点打分算法、缓存设计、插件单元测试与集成测试。
3. 进阶篇（第 16–25 章）：多维度拓扑权重、动态拓扑更新、与现有调度插件协同、性能调优。
4. 实战篇（第 26–30 章）：部署到生产集群、监控与告警、故障排查、社区贡献指南。