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 AllocationDRA的出现这一切才真正迎来转机。根据 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”。但它无法回答以下任何一个关键问题业务诉求Device Plugin 能否表达我需要 A100 80GB 而非 40GB否只能靠节点标签间接筛选我需要两张卡通过 NVLink 互联否拓扑信息完全丢失我只需要 10GB 显存能否共享一张卡否设备只能整数分配我能否将一张卡切成 1g.10gb 的 MIG 分区否需在节点侧手动预配置为什么这对 AI/ML 工作负载是致命的现代 AI/ML 工作负载有几个鲜明特征恰好击中了 Device Plugin 的软肋跨多节点扩展大模型训练动辄需要数百张 GPU节点间的高速互联如 InfiniBand拓扑必须被调度器感知。特定互联拓扑同一 Pod 内的容器若要走张量并行最好落在同一 NVSwitch 域内。动态共享与分区推理服务白天高峰需要更多卡、夜间低谷可以释放给训练任务弹性是刚需。用一个不透明整数来表达上述任何一项诉求无异于缘木求鱼。社区迫切需要一套结构化、可表达、可调度的新机制。这就是 DRA 诞生的背景。DRA架构深度解析DRADynamic Resource Allocation不是对 Device Plugin 的小修小补而是一次架构层面的重新设计。它引入了两个核心 API 对象——ResourceSlice和ResourceClaim并定义了清晰的生命周期。Device Management Working GroupDRA 的推进由 Kubernetes 的Device Management Working Group主导三位 co-chair 分别来自三家头部厂商阵容堪称豪华姓名职务公司Kevin KluesDistinguished EngineerNVIDIAPatrick OhlyPrincipal EngineerIntelJohn BelamaricSenior Staff SWEGoogle这是一个跨 SIG 协作的工程涉及五个 SIGsig-node设备在节点上的准备与暴露sig-scheduling调度器对硬件的智能匹配sig-autoscaling硬件资源的弹性伸缩sig-networkNIC、带宽等网络设备的建模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 ParametersKEP-4381调度器无需调用外部 webhook 就能在内存中完成匹配性能远超早期的 DRA kubelet-plugin 方案。阶段四Actuation执行系统完成设备准备和安全配置的握手过程。调度器选定设备后节点上的 DRA 驱动负责真正把设备挂载进容器、配置 MIG 分区、设置 cgroup 限制。这一阶段确保调度决策与实际就绪之间的一致性。一句话概括Modeling 让硬件自我介绍Requesting 让用户提需求Scheduling 让系统做媒Actuation 让双方握手成婚。GPU共享与分区技术DRA 解决了如何描述和调度硬件但 GPU 成本压力要求我们进一步把一张卡掰成多份用。社区与生态形成了三种主流的共享/分区技术。1. MIG硬件级分区MIGMulti-Instance GPU是 NVIDIA 从 Ampere 架构A100/A30开始引入的硬件分区能力。它以物理方式将一张 GPU 划分为多个独立实例每个实例拥有专用的显存Memory缓存Cache流式多处理器SMStreaming Multiprocessor对操作系统和 Kubernetes 而言这些实例看起来就像独立的 PCI 设备彼此硬件隔离一个实例崩溃不会影响另一个。这是目前隔离性最强的 GPU 共享方案。DRA 通过 KEP-4815Partitionable Devices将 MIG 分区能力纳入原生调度支持可重叠分区——调度器可动态选择 MIG 分区并自动使重叠的分区不可用避免冲突。2. HAMi软件级虚拟化HAMi原 k8s-vgpu-scheduler是一个开源扩展调度器在 K8S 环境中虚拟化 GPU 资源vGPU。它的核心优势设备共享同一 Pod 中多个容器可以共享同一张 GPU。零修改无需修改现有程序对上层应用完全透明。Helm 一键安装部署门槛极低。HAMi 的实战效果有真实案例佐证。SNOW CORPCNCF 案例研究曾面临 GPU 利用率低、流水线代码需要大规模重写的困境。引入 HAMi 后GPU 使用率提升2 倍且现有程序零修改即完成迁移。3. 时间分片简单但有风险时间分片Time-Slicing让多个进程通过时间片轮转共享同一张 GPU实现简单、无需特殊硬件支持。但它有一个显著缺陷隔离性弱。一个进程中的致命错误会影响共享该卡的其他进程极端情况下可能导致 GPU 重置殃及所有租户。三种方案的对比如下维度MIGHAMi时间分片隔离级别硬件级最强软件级较强进程级最弱是否需要特殊硬件是Ampere否否显存隔离物理隔离限额隔离共享可能 OOM部署复杂度中需预配置低Helm低故障影响范围单实例单容器整卡可能重置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按显存筛选以下模板声明请求任何显存大于 40GB40000MB的 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-70BapiVersion: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.defaultMemory8000\--setscheduler.kubeScheduler.imageTagv1.34.0\-nkube-system部署后业务 Pod 只需按nvidia.com/vgpu资源请求显存即可resources:limits:nvidia.com/vgpu:1# 1个vGPUnvidia.com/gpumem:8000# 限制8GB显存KAI SchedulerAI 推理的智能调度在更高阶的自动化层面KAI Scheduler由 Kubex 提供展示了 AI 调度 AI 的未来形态。它是一个自动化 GPU 共享的 AI 推理调度器具备使用机器学习预测模型主动管理 GPU 分数实时调整 GPU 分数以应对需求变化提供共享感知的 GPU 可观测性这相当于给调度器装上了预测大脑能在流量洪峰到来前就完成 GPU 资源的再分配。KEP路线图与未来展望DRA 的能力是通过一系列 KEPKubernetes Enhancement Proposal逐步构建的。以下是 1.32 至 1.36 期间关键 KEP 的成熟度进展KEP描述1.341.351.364381DRA: Structured ParametersStable--5004DRA: Extended Resource Requests via DRAAlphaAlphaBeta4817DRA: Resource Claim StatusBetaBetaBeta5018DRA: Namespace Controlled Admin AccessBetaBetaStable5055DRA: Device Taints and TolerationsAlphaAlphaBeta4816DRA: Prioritized AlternativesBetaBetaStable5075DRA: Consumable CapacityAlphaAlphaBeta4815DRA: Partitionable DevicesAlphaAlphaBeta5304DRA: Attributes Downward API--Alpha5729DRA: ResourceClaim Support for Workloads--Alpha4680Resource Health Status in Pod StatusAlphaAlphaBeta5517DRA: Native Resource Requests--Alpha路线图解读从这张表可以读出几条清晰的技术脉络核心已稳固KEP-4381Structured Parameters在 1.34 已 Stable是整个 DRA 调度性能的基石意味着调度器可在内存中完成匹配无需外部 webhook。共享能力在加速KEP-5075Consumable Capacity和 KEP-4815Partitionable Devices从 Alpha 推进到 Beta标志着 GPU 共享与 MIG 分区正在走向生产可用。运维能力在补齐KEP-5018Admin Access、KEP-5055Taints/Tolerations、KEP-4680Resource Health Status都在向 Beta/Stable 推进说明社区在补齐故障隔离、运维管理的短板。1.36 引入新能力KEP-5304Attributes Downward API、KEP-5729ResourceClaim Support for Workloads、KEP-5517Native 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 社区已经帮我们造好了。
)
