GPU 资源控制面地图
只有厘清控制面与数据平面的分工，才能避免 GPU 平台建设中的常见误区，实现治理与资源兑现的协同。
本章将为全书提供“架构坐标系”。控制面（Control Plane）主要解决队列、配额、优先级、公平性与准入等治理问题；数据平面（Data Plane）则聚焦于设备发现、切分与虚拟化、隔离、可观测与计量等资源兑现环节。通过本章的学习，你将掌握如何定位一个项目所解决的问题层级，以及不同层之间如何组合成端到端方案，避免将不相关的能力混为一谈。
这张地图要解决什么问题
在 GPU 平台建设过程中，最大的认知陷阱之一是将“调度器/队列/配额”与“虚拟化/切分/隔离”混为一谈，并用同一套指标去比较所有项目，最终导致难以落地的结论。
为此，本书采用一张简明但足够有力的分层地图，将 GPU 资源体系拆解为两个正交面：
- 控制面（Control Plane）：决定“谁能用、何时能用、能用多少、以什么优先级用、用不够时谁让路”。典型能力包括队列化、配额、准入、抢占、策略（公平性/优先级/拓扑偏好）等。Kueue 属于这一类。
- 数据平面（Data Plane）：决定“GPU 如何被暴露、如何被切分与隔离、如何被实际分配给容器、如何被计量与观测”。典型能力包括 device plugin 分配流程、MIG（Multi-Instance GPU）切分，以及健康检查等。
两者的关系可以类比为：控制面负责“秩序与治理”，数据平面负责“兑现与约束”。如果缺乏控制面，系统可能“能跑但混乱”；如果缺乏数据平面，则“规则很好但无法落地”。
下图展示了控制面与数据平面的核心关系及常见组件的分工：
GPU 控制面地图：从组织治理到节点分配的五层
下文将通过五个层级，帮助你定位任何组件或方案在整个体系中的位置。这五层自上而下逐步收敛，越往下越接近“实际把 GPU 交到容器手里”。
以下图示展示了五层架构的完整体系：
Layer 0：工作负载单元（Workload Unit, WU）
在控制面治理中，关注的对象并非“单个 Pod”，而是“一个业务作业单元（Workload Unit, WU）”。这可以是分布式训练的一组 Pod、一个推理服务的扩缩容组、一个 Ray 作业，或是一批离线推理任务。
本层需要明确两个关键问题：
- 资源请求是“单 Pod”还是“一组 Pod”的原子集合？
- 如果是集合，能否接受部分启动？还是必须“全有或全无”（典型分布式训练需要这种语义）？
Layer 1：入口治理（Admission & Quota）
本层是控制面的核心“组织治理层”，主要解决“谁先开始、谁等待、谁被抢占”等问题。
以 Kueue 为例，其定位非常清晰：管理配额及作业如何消耗配额，并决定作业何时等待、何时被准入（允许创建 Pod）、何时被抢占（删除已运行的 Pod）。 Kubernetes 官方对 Kueue 的介绍也强调：它是 job queueing controller，按“作业单元”管理批处理作业，并将 Pod 级编排交由 Kubernetes 的稳定组件处理。
本层的核心产出不是“把 Pod 调度到哪”，而是：
- 形成队列与优先级秩序，避免资源争抢导致的组织冲突
- 形成可解释的配额承诺（资源承诺/归还、可审计）
Layer 2：全局调度策略（Scheduling Policy）
本层决定“调度算法与策略语义”。可以理解为：当一批作业被允许进入集群后，如何在节点层面实现公平与效率。
Volcano 的官方文档列举了其丰富的调度策略：gang scheduling、公平共享、队列调度、抢占、拓扑感知、回收、回填、资源预留等。 这表明 Volcano 更像“策略型调度器/批处理调度系统”，强调作业级语义与策略插件化，而非数据平面的虚拟化机制。
本层主要解决以下典型矛盾：
- 分布式训练的协同调度（co-scheduling），避免部分成功导致资源碎片
- 多团队公平性（fair-share / queue）
- 资源紧张时的抢占与回填，提升总体吞吐
Layer 3：Kubernetes 编排闭环（Pod Orchestration）
无论上层采用 Kueue 还是 Volcano，最终都要回到 Kubernetes 的“Pod 生命周期”闭环：创建、调度、绑定、运行、重试、终止。
Kueue 的一个关键设计点是“准入发生在 Pod 创建之前”：当作业未被准入时，Pod 不会创建，从而避免大量 Pending Pod 堆积在集群中，减少资源死锁与噪声。
本层关注工程可控性：
- 控制面是否将“等待”表达为可治理对象（Workload/Queue），而非让集群充满 Pending Pod？
- 控制面能否与现有 workload controller（如 Job 或自定义 CRD）形成稳定集成？
Layer 4：节点分配与设备交付（Node Allocation & Device Handoff）
本层是控制面与数据平面的交界处：调度器决定 Pod 去哪个节点，节点侧负责将“具体 GPU 设备/实例”交付给容器。
Kubernetes 的 device plugin 框架定义了 kubelet 与 device plugin 的交互方式：设备插件以 gRPC 方式注册并汇报健康状态，并在 Allocate 阶段为容器做设备级准备与分配。
NVIDIA 的 Kubernetes device plugin 以 DaemonSet 形式运行，负责在节点上暴露 GPU 数量、跟踪健康状态，并允许运行 GPU 容器。
需要注意的是，许多“误判根因”都发生在本层：表面上是调度失败，实际问题可能出在 Allocate/设备准备阶段，反之亦然。
项目放置表：常见组件在地图中的定位
下表用于快速定位常见组件或机制在五层地图中的主要归属、核心作用及常见误用场景。
| 组件/机制 | 主要所在层 | 核心回答的问题 | 常见误用 |
|---|---|---|---|
| Kueue | Layer 1（入口治理） | 谁等待、谁准入、配额如何被消耗与回收 | 用它去“提升单节点 GPU 利用率” |
| Volcano | Layer 2（全局策略） | 批处理/训练语义、队列、公平、gang、抢占等 | 把它当作“GPU 虚拟化”方案 |
| kube-scheduler（原生） | Layer 2/3 | Pod 级调度与绑定 | 期望它理解显存/拓扑等连续变量 |
| Device Plugin（框架） | Layer 4 | 节点设备发现、健康、Allocate 交付 | 期望它解决队列与配额治理 |
| MIG（机制） | 数据平面（交付到 Layer 4） | 把一张 GPU 切成多个隔离实例 | 期望它解决跨团队公平与准入 |
| NVIDIA k8s-device-plugin | Layer 4（实现） | 暴露 GPU、健康、容器可用性 | 误以为它能自动带来共享与隔离策略 |
其中，MIG（Multi-Instance GPU）机制可以作为理解“数据平面资源单位”的锚点：它能够将一张支持 MIG 的 GPU 划分为多个彼此隔离的实例，每个实例拥有专用的计算与内存资源。
三种典型架构范式：控制面如何选型
在实际平台建设中，常见的控制面架构范式有三种，分别适用于不同的业务场景。
下图展示了三种范式的特点与适用场景对比：
范式 A：原生 Kubernetes（最小闭环）
- 入口治理能力有限，主要依赖 Namespace、ResourceQuota 及组织流程
- 调度策略以 Pod 级为主
- 设备交付依赖 device plugin（通常为 NVIDIA plugin）
适用场景：单团队、小规模、以整卡独占为主的早期阶段。
范式 B：Volcano 作为策略调度器（偏“训练/批处理平台”）
- 强调作业级策略，如 gang、fair-share、queue、preemption 等
- 常用于训练/批处理密集场景，尤其适合需要协同调度的作业形态
适用场景：训练集群、批处理集群、需要强策略表达的场景。
范式 C：Kueue 作为入口治理（偏“多租户资源治理”）
- 将“等待/准入/抢占”显式化为治理对象，减少 Pending Pod 噪声
- 调度器可保持原生，或在策略层做适度扩展，重点建立治理秩序
适用场景：多团队共享资源池、需要配额承诺与可审计的组织型平台。
需要注意的是，这三种范式仅讨论控制面选型，并不决定最终采用 MIG、HAMi 或其他机制作为数据平面。正确的做法是先明确治理模式，再决定资源单位与隔离强度的落地方式。
控制面与数据平面的接口：需要关注的三个“契约点”
在实际系统中，控制面与数据平面之间存在三个关键契约点：
下图展示了这三个契约点在系统中的角色及常见问题场景：
详细说明如下：
- 资源广告（Advertise）：节点将可用 GPU（整卡或 MIG 实例）以资源形式暴露给集群。
- 调度绑定（Bind）：调度器选择节点并完成 Pod 到 Node 的绑定。
- 设备分配（Allocate）：kubelet 调用 device plugin 的 Allocate，完成设备交付与容器启动前准备。
许多系统性问题都源于契约未能成立：如控制面认为资源可用，但数据平面交付失败；或数据平面可交付，但控制面缺乏准入/配额，导致整体秩序混乱。
与本书实验环境的对应关系
结合本书实验环境（两台 A100，其中一台启用 MIG），你可以将上述地图快速映射到实际证据链：
- Lab 0 固化 Layer 4 的基础事实：驱动、CUDA、设备可见性与健康状态（否则所有上层结论都不可信）。
- Lab 1（MIG） 具象化“数据平面资源单位”：实例隔离带来的稳定性收益，以及 profile 离散与重配置成本。
- Lab 2（无 MIG 共享） 展示“缺乏数据平面约束时”，控制面难以对 P99 做出承诺。
- Lab 3（HAMi） 验证“共享可声明、可治理”是否能在 Layer 4 的交付层闭环兑现，以及其与 Layer 1/2 的组合空间。
总结
本章提出的“GPU 资源控制面地图”并不追求复杂，而在于为后续所有项目、机制与实验提供一个长期可复用的比较框架：
- 首先明确：你要解决的是治理秩序（控制面），还是资源兑现（数据平面）。
- 再选组件：Kueue、Volcano 属于控制面不同侧重点；MIG、设备插件属于数据平面资源单位与交付层。
- 最后用实验闭环，将“理论优点”转化为“可验收指标”。
下一章将聚焦 Kubernetes 的资源表达与边界：为什么原生语义天然偏向整卡、device plugin 能解决什么/不能解决什么，以及这些因素如何影响后续的虚拟化与共享方案选择。