📚 课程目录第1章课程导入

1. 课程导入

在传统互联网业务中，Kubernetes 调度器面对的多是长期运行的无状态服务：一个 Pod 申请 0.5 核 CPU、512MiB 内存，调度器把它放到资源足够的节点上，之后它就一直待在那里。而 AI 任务完全不同——一次分布式训练可能同时拉起 64 个 Worker，每个 Worker 需要 8 张 GPU、跨节点高速互联，训练 3 小时后全部退出；一次推理服务又要求 GPU 常驻、延迟稳定在 50ms 以内。把这两类负载放进同一个集群，调度器要回答的问题就从"哪个节点有空位"变成了"这组任务能不能同时拿到资源、放在哪里通信最快、什么时候该抢占、什么时候该排队"。

这就是本课程要讨论的 Kubernetes AI 任务调度工程：它不是简单地"给 Pod 加一个 GPU 字段"，而是一套围绕 AI 负载特征，对资源模型、调度策略、队列管理、拓扑感知、弹性伸缩进行系统性设计与工程化的方法体系。它的目标可以概括为三个可度量的方向：资源利用率（GPU 空转时间占比）、任务完成效率（排队时长 + 运行时长，即 JCT）、关键任务保障（高优先级任务能否按时拿到资源）。

AI 负载给调度带来的四类核心挑战

理解调度工程，先要理解 AI 负载与普通负载的差异。这些差异直接决定了后面每一章要解决的问题。

成组性（Gang Scheduling）：分布式训练的 64 个 Worker 必须全部就位才能开始，只调度成功 63 个等于 0。默认调度器逐个 Pod 调度，极易造成"部分占用、整体死锁"——资源被占住却没人能跑。
异构资源与拓扑：GPU 型号、显存、NVLink/NVSwitch 互联域、NUMA 节点、RDMA 网卡，都是调度时必须一起考虑的维度。把同一 AllReduce 组的两个 Worker 放到跨 Spine 的机架上，通信带宽可能下降数倍。
队列与公平性：多个团队共享集群时，需要配额（Quota）、优先级（PriorityClass）、抢占（Preemption）和公平分享（Fair Sharing）机制，避免一个团队的大任务把整个集群堵死。
弹性与成本：训练任务可中断、可重启，推理服务不可中断；需要区分在线/离线，结合 Spot 实例、节点池自动扩缩容来控制成本。

下面这张图把上述关系组织成一张"调度决策链路"视图：从任务提交，到队列准入、成组校验、拓扑打分，最终落到节点绑定，并标出每一环对应的核心机制与失败后果。

从"能跑"到"跑得好"：学习路径

本课程按"资源—调度—队列—拓扑—弹性—运维"的顺序推进，每一层都建立在前一层之上。建议的学习路径如下：

资源模型层：理解 GPU 如何被 Kubernetes 识别（Device Plugin）、如何被切分（MIG / 时间片共享）、如何被声明（resources.limits 中的 nvidia.com/gpu）。这是所有调度的前提。
调度框架层：掌握 kube-scheduler 的 Filter / Score / Reserve / Bind 扩展点，理解为什么默认调度器无法直接满足 AI 需求，以及如何通过 Scheduler Framework 插件介入。
成组与队列层：学习 Volcano、Kueue、YuniKorn 等调度系统如何实现 Gang Scheduling、队列配额与公平分享。
拓扑感知层：掌握 NUMA、NVLink、RDMA 拓扑如何暴露给调度器，以及 Topology Aware Scheduling 的打分逻辑。
弹性与成本层：结合 Cluster Autoscaler、Karpenter、Spot 实例，设计可中断训练与不可中断推理的混合部署策略。
可观测与调优层：用 DCGM、调度器指标、事件审计构建反馈闭环，把"调参"变成"有依据的迭代"。

学习建议：每学完一层，回到自己的集群做一次小实验。例如学完资源模型后，提交一个申请 1 张 GPU 的 Pod，观察它是否被正确调度、GPU 是否真正被占用（用 nvidia-smi 验证）。调度工程是"看得见"的工程，脱离集群的学习效果会大打折扣。

整体知识框架与一个可运行的起点

把上面的路径压缩成一张知识地图，可以用四个同心层来理解：最内层是资源（GPU、显存、网络），第二层是调度（Filter/Score/Bind），第三层是策略（队列、优先级、抢占、公平），最外层是运维（观测、弹性、成本）。四层之间是双向的：运维数据反馈给策略，策略约束调度，调度依赖资源模型。

为了让课程从一开始就可操作，下面给出一个最小可用的验证示例。假设集群已安装 NVIDIA Device Plugin，提交一个单卡任务：

apiVersion: v1
kind: Pod
metadata:
  name: gpu-check
spec:
  containers:
  - name: cuda
    image: nvidia/cuda:12.4.0-base-ubuntu22.04
    command: ["nvidia-smi", "-L"]
    resources:
      limits:
        nvidia.com/gpu: 1
  restartPolicy: Never

应用后观察三件事：kubectl get pod gpu-check -o wide 看它落在哪个节点；kubectl describe pod gpu-check 看 Events 中是否有 Insufficient nvidia.com/gpu；进入容器执行 nvidia-smi -L 确认能看到 GPU 设备。如果 Pod 一直 Pending，说明资源模型或节点标签有问题——这正是后续章节要系统解决的第一类问题。

常见误区：认为"集群里有 GPU，Pod 就一定能用上"。实际上 GPU 必须经过 Device Plugin 注册为扩展资源，节点上还要有对应的标签与污点配置，调度器才会把它纳入可分配资源。跳过资源模型直接学调度策略，往往会在最基础的地方卡住。

接下来的章节会沿着这条链路逐层展开：先把资源模型讲透，再进入调度框架，然后是成组调度、队列管理、拓扑感知、弹性伸缩与可观测性。每一章都会给出可执行的配置、可观察的指标和可判断的结果，帮助你把"调度"从黑盒变成可设计、可验证、可优化的工程系统。