1. 课程导论：网络拓扑感知调度器的背景、价值与课程目标
1.1 背景：传统调度器的“拓扑盲区”
Kubernetes 默认调度器（kube-scheduler）在分配 Pod 时，主要依据节点资源水位（CPU、内存）和用户定义的亲和性规则。它并不感知底层网络拓扑——例如节点所在的机架、交换机层级、跨可用区的链路带宽与延迟。这种“拓扑盲区”在以下场景中会引发严重的性能与成本问题：
- 分布式训练（ML/DL）：Pod 间需要高频 AllReduce 通信，若跨机架或跨交换机调度，通信延迟会显著增加，训练效率下降 30%~50%。
- 有状态数据库（Cassandra、TiDB）：副本应分布在不同的故障域（机架/可用区），但默认调度器可能将多个副本调度到同一机架，导致单点故障。
- 实时音视频（RTC）：媒体流对延迟极其敏感，Pod 应尽量调度到同一交换机下或同一可用区内。
- 成本优化：跨可用区流量通常需要额外收费，拓扑感知调度可减少不必要的跨区通信。
核心痛点： 默认调度器将集群视为“扁平资源池”，忽略了物理网络拓扑对应用性能、可靠性和成本的决定性影响。
1.2 价值：网络拓扑感知调度带来的收益
通过在调度器中引入网络拓扑感知能力，可以实现以下关键价值：
| 维度 | 传统调度 | 拓扑感知调度 | 收益量化 |
|---|---|---|---|
| 通信延迟 | Pod 可能跨 3~4 层交换机 | Pod 优先同机架/同交换机 | 延迟降低 40%~70% |
| 训练吞吐 | AllReduce 跨机架带宽受限 | AllReduce 在机架内完成 | 吞吐提升 2~5 倍 |
| 故障域隔离 | 副本可能集中在同一机架 | 副本强制分布到不同机架/可用区 | RTO 降低 60% |
| 跨区流量成本 | 无感知，可能产生大量跨区流量 | 优先同区调度，减少跨区流量 | 网络成本降低 20%~40% |
适用场景速查： 如果你的集群运行着 MPI 作业、分布式数据库、实时流处理或 AI 推理服务，拓扑感知调度几乎可以立即带来可量化的收益。
1.3 课程目标：从零构建一个 Helm 化的拓扑感知调度器插件
本课程将带领你完成以下核心目标：
- 理解调度器扩展机制：掌握 Kubernetes 调度框架（Scheduling Framework）中的 Filter、Score、PreScore、Reserve 等扩展点。
- 设计网络拓扑模型：学习如何用 NodeLabel、NodeAnnotation 或自定义 CRD 表达机架、交换机、可用区等拓扑层级。
- 实现拓扑感知插件：编写一个自定义调度器插件，在 Filter 阶段过滤拓扑不匹配的节点，在 Score 阶段为拓扑更优的节点加分。
- Helm Chart 打包与部署：将插件及其依赖（RBAC、ConfigMap、Deployment）封装为 Helm Chart，实现一键安装与配置。
- 集成与验证：在真实或模拟集群中部署插件，通过测试 Pod 验证调度结果是否符合拓扑约束。
前置要求： 本课程假设你已熟悉 Kubernetes 基本概念（Pod、Node、Label）、Helm 基础操作（install/upgrade/template）以及 Go 语言基础。如果你对调度框架完全陌生，建议先阅读 Kubernetes 官方文档中关于“Scheduling Framework”的章节。
1.4 课程知识体系总览
下图展示了本课程的核心知识模块及其依赖关系：
1.5 课程产出物
完成本课程后，你将获得以下可直接复用的产出物：
| 产出物 | 说明 | 交付形式 |
|---|---|---|
| 拓扑感知调度器插件 | 基于 Kubernetes Scheduling Framework 的 Filter + Score 插件 | Go 源码 + 编译后的二进制 |
| Helm Chart | 包含插件 Deployment、ServiceAccount、RBAC、ConfigMap 的 Chart 包 | tgz 归档 + values.yaml |
| 拓扑标签规范 | 推荐使用的 NodeLabel 命名与层级约定文档 | Markdown 文档 |
| 集成测试脚本 | 用于验证调度结果的自动化测试脚本（Shell + Python） | Shell / Python 脚本 |
课程定位： 本课程不是纯理论讲解，而是“手把手带你写一个生产可用的 Helm 化调度器插件”。每章都包含可运行的代码示例和实验步骤，建议你边学边练。