Kubernetes GPU调度新纪元：DRA、MIG与GPU共享的云原生AI实践

当 Llama-3.3-70B 这样的百亿参数模型成为推理标配，当单张 A100 80GB 的价格足以让任何 CFO 皱眉，Kubernetes 社区终于给出了一个系统级答案——DRA 在 1.34 正式 GA 毕业。本文带你从 Device Plugin 的历史困境出发，深入剖析 DRA 的四阶段架构、GPU 共享与分区技术，并给出可落地的实战 YAML。

目录

• 引言：AI工作负载带来的硬件管理挑战
• 旧时代的困境：Device Plugin API的局限性
• DRA架构深度解析：四阶段生命周期
• GPU共享与分区技术
• 实战部署方案
• KEP路线图与未来展望
• 结语

引言

2026 年的云原生 AI 实践，早已不再是"挂载一张 GPU、跑一个容器"那么简单。大模型推理与训练工作负载对硬件提出了前所未有的细粒度诉求：

• 显存容量敏感：70B 参数模型以 FP16 加载需要约 140GB 显存，单卡难以承载，必须跨卡甚至跨节点。
• 互联拓扑敏感：张量并行（Tensor Parallelism）严重依赖 NVLink 高带宽互联，错误的拓扑会导致性能断崖式下跌。
• 成本敏感：一张 H100 动辄数万美元，GPU 利用率每提升 10 个百分点，就意味着真金白银的节省。
• 共享与分区敏感：训练任务独占整卡，而推理任务可能只需要 1/4 张卡，混部调度成为刚需。

然而，长期以来 Kubernetes 对这类硬件的管理能力，停留在"把设备当作一个不透明整数"的水平。直到Dynamic Resource Allocation（DRA）的出现，这一切才真正迎来转机。根据 Kubernetes 官方博客 2026 年 6 月 24 日的发布信息，DRA 在 Kubernetes 1.34 正式 GA 毕业，标志着云原生 AI 硬件调度进入新纪元。

旧时代的困境

Device Plugin API：一个"整数"的故事

自 Kubernetes 1.8 起，Device Plugin API 是挂载加速器、GPU、RDMA 网卡等异构硬件的标准方式。它的核心抽象极其简单：设备是一个不透明的整数。

# 旧时代：只能请求"数量"，无法表达任何细节resources:limits:nvidia.com/gpu:2# 2个GPU，但什么样的GPU？怎么互联？能共享吗？一无所知

这段 YAML 的语义是：“给我 2 个 GPU”。但它无法回答以下任何一个关键问题：

为什么这对 AI/ML 工作负载是致命的

现代 AI/ML 工作负载有几个鲜明特征，恰好击中了 Device Plugin 的软肋：

1. 跨多节点扩展：大模型训练动辄需要数百张 GPU，节点间的高速互联（如 InfiniBand）拓扑必须被调度器感知。
2. 特定互联拓扑：同一 Pod 内的容器若要走张量并行，最好落在同一 NVSwitch 域内。
3. 动态共享与分区：推理服务白天高峰需要更多卡、夜间低谷可以释放给训练任务，弹性是刚需。

用一个不透明整数来表达上述任何一项诉求，无异于缘木求鱼。社区迫切需要一套结构化、可表达、可调度的新机制。这就是 DRA 诞生的背景。

DRA架构深度解析

DRA（Dynamic Resource Allocation）不是对 Device Plugin 的小修小补，而是一次架构层面的重新设计。它引入了两个核心 API 对象——ResourceSlice和ResourceClaim，并定义了清晰的生命周期。

Device Management Working Group

DRA 的推进由 Kubernetes 的Device Management Working Group主导，三位 co-chair 分别来自三家头部厂商，阵容堪称豪华：

这是一个跨 SIG 协作的工程，涉及五个 SIG：

• sig-node：设备在节点上的准备与暴露
• sig-scheduling：调度器对硬件的智能匹配
• sig-autoscaling：硬件资源的弹性伸缩
• sig-network：NIC、带宽等网络设备的建模
• sig-architecture：整体 API 与概念的设计一致性

四阶段生命周期

DRA 的精髓在于将"硬件分配"这件事拆解成四个解耦的阶段，让每个阶段各司其职。

阶段一：Modeling（建模）

厂商通过ResourceSliceAPI 发布硬件的粒度能力和容量。这是"声明硬件有什么"的阶段。

例如，NVIDIA 的 DRA 驱动会发布如下信息：这张卡是 A100，有 80GB 显存，支持 MIG，当前可用的分区有哪些，是否在某个 NVLink 域内。这些结构化属性是后续一切调度的数据基础。

阶段二：Requesting（请求）

用户通过ResourceClaimAPI 定义具体硬件需求。这是"声明我要什么"的阶段。DRA 的请求语言非常丰富，支持：

• 按属性请求：不只是"1 个 GPU"，而是"任何 20GB 以上显存的 GPU"。
• 备选列表："我想要 1 个 A100(80GB)，如果没有就给我 2 个 A100(40GB)"。
• 拓扑约束：可以要求多张卡处于同一互联域。

阶段三：Scheduling（调度）

K8S 调度器智能匹配工作负载需求与可用硬件。得益于结构化参数（Structured Parameters，KEP-4381），调度器无需调用外部 webhook 就能在内存中完成匹配，性能远超早期的 DRA kubelet-plugin 方案。

阶段四：Actuation（执行）

系统完成设备准备和安全配置的"握手"过程。调度器选定设备后，节点上的 DRA 驱动负责真正把设备挂载进容器、配置 MIG 分区、设置 cgroup 限制。这一阶段确保"调度决策"与"实际就绪"之间的一致性。

一句话概括：Modeling 让硬件"自我介绍"，Requesting 让用户"提需求"，Scheduling 让系统"做媒"，Actuation 让双方"握手成婚"。

GPU共享与分区技术

DRA 解决了"如何描述和调度硬件"，但 GPU 成本压力要求我们进一步把一张卡掰成多份用。社区与生态形成了三种主流的共享/分区技术。

1. MIG：硬件级分区

MIG（Multi-Instance GPU）是 NVIDIA 从 Ampere 架构（A100/A30）开始引入的硬件分区能力。它以物理方式将一张 GPU 划分为多个独立实例，每个实例拥有专用的：

• 显存（Memory）
• 缓存（Cache）
• 流式多处理器（SM，Streaming Multiprocessor）

对操作系统和 Kubernetes 而言，这些实例看起来就像独立的 PCI 设备，彼此硬件隔离，一个实例崩溃不会影响另一个。这是目前隔离性最强的 GPU 共享方案。

DRA 通过 KEP-4815（Partitionable Devices）将 MIG 分区能力纳入原生调度，支持可重叠分区——调度器可动态选择 MIG 分区，并自动使重叠的分区不可用，避免冲突。

2. HAMi：软件级虚拟化

HAMi（原 k8s-vgpu-scheduler）是一个开源扩展调度器，在 K8S 环境中虚拟化 GPU 资源（vGPU）。它的核心优势：

• 设备共享：同一 Pod 中多个容器可以共享同一张 GPU。
• 零修改：无需修改现有程序，对上层应用完全透明。
• Helm 一键安装：部署门槛极低。

HAMi 的实战效果有真实案例佐证。SNOW CORP（CNCF 案例研究）曾面临 GPU 利用率低、流水线代码需要大规模重写的困境。引入 HAMi 后，GPU 使用率提升2 倍，且现有程序零修改即完成迁移。

3. 时间分片：简单但有风险

时间分片（Time-Slicing）让多个进程通过时间片轮转共享同一张 GPU，实现简单、无需特殊硬件支持。但它有一个显著缺陷：隔离性弱。一个进程中的致命错误会影响共享该卡的其他进程，极端情况下可能导致 GPU 重置，殃及所有租户。

三种方案的对比如下：

DRA 的共享模型

DRA 在共享层面提供了两种优雅的模型：

• 显式共享（User-mediated sharing）：多个容器/Pod 指向同一个ResourceClaim，只要设备支持即可共享。用户是共享的发起者。
• 平台中介共享（Platform-mediated sharing / Consumable Capacity）：类似 Pod 共享 Node 的方式。用户创建ResourceClaim请求特定资源量（如"需要 2Gbps 带宽的 NIC"），调度器从 40Gbps 的总容量中分配 2Gbps。这是 KEP-5075 的核心，让资源像"水龙头"一样可计量、可分配。

实战部署方案

下面给出一个完整的实战方案，演示如何在 K8S 1.34+ 上通过 DRA 调度 GPU，并展示 MIG 分区与 Pod 使用 ResourceClaim 的完整链路。

步骤一：定义 ResourceClaimTemplate（按显存筛选）

以下模板声明：请求任何显存大于 40GB（40000MB）的 GPU，数量上限 1 个。这是 DRA "按属性请求"能力的直接体现。

apiVersion:resource.k8s.io/v1beta1kind:ResourceClaimTemplatemetadata:name:gpu-claim-templatespec:metadata:name:gpu-claimspec:devices:requests:-name:gpudeviceClassName:gpu.nvidia.comselectors:-cel:expression:|device.attributes['gpu.nvidia.com'].memory >= 40000limits:-gpu:1

注意selectors.cel.expression使用的是 CEL 表达式，调度器在内存中即可完成筛选，无需外部调用。

步骤二：定义 MIG 分区模板

以下模板通过 DRA Partitionable Devices 能力，请求一个1g.10gb大小的 MIG 分区：

apiVersion:resource.k8s.io/v1beta1kind:ResourceClaimTemplatemetadata:name:mig-partition-templatespec:spec:devices:requests:-name:mig-slicedeviceClassName:mig.nvidia.comselectors:-cel:expression:|device.attributes['gpu.nvidia.com'].partitionSize == '1g.10gb'

步骤三：Pod 使用 ResourceClaim 运行推理

以下 Pod 使用gpu-claim-template调度一张满足显存要求的 GPU，运行 vLLM 推理服务加载 Llama-3.3-70B：

apiVersion:v1kind:Podmetadata:name:llm-inferencespec:containers:-name:vllmimage:vllm/vllm-openai:latestargs:["--model","meta-llama/Llama-3.3-70B-Instruct","--tensor-parallel-size","1"]resources:claims:-name:gpuresourceClaims:-name:gpuresourceClaimTemplateName:gpu-claim-template

步骤四：HAMi 一键部署

对于不想等 DRA 全家桶成熟、希望立即享受 GPU 共享红利的团队，HAMi 是务实之选。一条 Helm 命令即可完成部署：

helminstallhami hami-charts/hami\--setdevicePlugin.nvidia.defaultMemory=8000\--setscheduler.kubeScheduler.imageTag=v1.34.0\-nkube-system

部署后，业务 Pod 只需按nvidia.com/vgpu资源请求显存即可：

resources:limits:nvidia.com/vgpu:1# 1个vGPUnvidia.com/gpumem:8000# 限制8GB显存

KAI Scheduler：AI 推理的智能调度

在更高阶的自动化层面，KAI Scheduler（由 Kubex 提供）展示了 AI 调度 AI 的未来形态。它是一个自动化 GPU 共享的 AI 推理调度器，具备：

• 使用机器学习预测模型主动管理 GPU 分数
• 实时调整 GPU 分数以应对需求变化
• 提供共享感知的 GPU 可观测性

这相当于给调度器装上了"预测大脑"，能在流量洪峰到来前就完成 GPU 资源的再分配。

KEP路线图与未来展望

DRA 的能力是通过一系列 KEP（Kubernetes Enhancement Proposal）逐步构建的。以下是 1.32 至 1.36 期间关键 KEP 的成熟度进展：

路线图解读

从这张表可以读出几条清晰的技术脉络：

1. 核心已稳固：KEP-4381（Structured Parameters）在 1.34 已 Stable，是整个 DRA 调度性能的基石，意味着调度器可在内存中完成匹配，无需外部 webhook。
2. 共享能力在加速：KEP-5075（Consumable Capacity）和 KEP-4815（Partitionable Devices）从 Alpha 推进到 Beta，标志着 GPU 共享与 MIG 分区正在走向生产可用。
3. 运维能力在补齐：KEP-5018（Admin Access）、KEP-5055（Taints/Tolerations）、KEP-4680（Resource Health Status）都在向 Beta/Stable 推进，说明社区在补齐故障隔离、运维管理的短板。
4. 1.36 引入新能力：KEP-5304（Attributes Downward API）、KEP-5729（ResourceClaim Support for Workloads）、KEP-5517（Native Resource Requests）三个全新 Alpha 进入视野，预示着 DRA 将更深度地与 Workloads API、Downward API 等集成。

未来展望

展望未来 1-2 个版本，我们可以期待：

• GPU 共享真正"开箱即用"：Consumable Capacity 进入 Beta 后，"按带宽/显存计量分配"将成为原生能力，HAMi 这类方案有望与 DRA 深度融合。
• MIG 分区动态化：Partitionable Devices 成熟后，调度器可按需动态切分 MIG，无需节点侧预配置。
• AI 原生调度器：KAI Scheduler 这类带 ML 预测能力的调度器，将与 DRA 的结构化属性深度结合，实现"预测式"GPU 分配。

结语

从 Device Plugin 的"不透明整数"，到 DRA 的"结构化、可表达、可调度"，Kubernetes 对异构硬件的管理能力完成了一次质的飞跃。DRA 在 1.34 的 GA 毕业不是终点，而是一个新纪元的起点。

回顾全文，我们看到了三层递进的能力栈：

• 底层：MIG 硬件分区提供最强隔离，时间分片提供最低门槛，HAMi 在两者间取得平衡。
• 中层：DRA 用四阶段生命周期（Modeling、Requesting、Scheduling、Actuation）将硬件"建模-请求-调度-执行"全链路打通。
• 上层：KAI Scheduler 等 AI 原生调度器带来预测式调度，让 GPU 分配从"响应式"走向"预测式"。

对于正在建设云原生 AI 平台的工程师而言，现在正是拥抱 DRA 的最佳时机。从 KEP 路线图可以看到，共享、分区、运维三大能力都在快速成熟。当这些能力齐备之时，"GPU 利用率翻倍"将不再是少数公司的案例神话，而是云原生 AI 平台的标配基线。

与其在旧时代的 Device Plugin 里打补丁，不如到 DRA 的新纪元里造轮子。这个轮子，Kubernetes 社区已经帮我们造好了。