K8s GPU调度从入门到“精通”不止Device Plugin还有MIG、DRA和那些你踩过的坑你以为把GPU挂上K8s就万事大吉了错调度策略、硬隔离、软隔离、抢占回收…每一个环节都可能是你烧钱的坑。本文从实战出发手把手教你如何让K8s集群的GPU利用率从20%飙升到80%。引言一个价值百万的教训某创业公司为了训练大模型采购了20台8卡A100服务器。运维用K8s默认调度所有人随便申请GPU。半年后一算账电费折旧人工花了300多万但模型的吞吐量还不如隔壁用vLLM部署的单机服务。更可怕的是有人开着GPU跑while true; do sleep 1; done一跑就是三天没人发现。这就是典型的“有资源无管理”的后果。今天我们就来填坑。一、K8s GPU调度的前世今生1.1 原生K8s对GPU的态度我不懂你自己搞K8s设计之初没考虑GPU因为那时候AI还没火。所以GPU在K8s里本质是扩展资源Extended Resource。直到Device Plugin机制出现才给了GPU一个“合法身份”。1.2 NVIDIA Device Plugin原理附关键代码Device Plugin是一个gRPC服务运行在每个节点上负责探测本节点的GPU数量向kubelet注册nvidia.com/gpu资源监听Pod的分配请求在容器启动前挂载GPU设备核心逻辑在device-plugin/nvidia-device-plugin.go的Allocate()方法中func(p*NvidiaDevicePlugin)Allocate(ctx context.Context,reqs*pluginapi.AllocateRequest)(*pluginapi.AllocateResponse,error){varresponses pluginapi.AllocateResponsefor_,req:rangereqs.ContainerRequests{// 收集被分配的设备IDvardeviceIDs[]stringfor_,id:rangereq.DevicesIDs{deviceIDsappend(deviceIDs,id)}// 生成环境变量和挂载点resp:pluginapi.ContainerAllocateResponse{Envs:map[string]string{NVIDIA_VISIBLE_DEVICES:strings.Join(deviceIDs,,),},Mounts:[]*pluginapi.Mount{{ContainerPath:/usr/local/nvidia,HostPath:/usr/local/nvidia},// ... 其他必要的挂载},}responses.ContainerResponsesappend(responses.ContainerResponses,resp)}returnresponses,nil}看到那个NVIDIA_VISIBLE_DEVICES了吗这就是nvidia-docker用来控制哪个GPU被注入容器的核心环境变量。二、从“能用”到“好用”MIG与时间片共享2.1 MIG硬隔离亲兄弟明算账A100/H100支持MIGMulti-Instance GPU可以把一张物理卡切成多个独立的实例每个实例有独立的计算核心、显存和内存带宽。配置示例在节点上创建MIG实例# 把一张A100切成7个1g.5gb实例nvidia-smi mig-cgi9,9,9,9,9,9,9-C然后在K8s中Pod就可以申请具体的MIG实例apiVersion:v1kind:Podmetadata:name:mig-podspec:containers:-name:trainerimage:pytorch/pytorch:latestresources:limits:nvidia.com/mig-1g.5gb:1优点真正的物理隔离不会互相干扰。缺点配置复杂且不能动态调整。2.2 时间片共享用“时间换空间”的折中方案如果你用的是T4、V100这类不支持MIG的卡又想共享GPU可以通过CUDA MPS或NVIDIA GPU Time Slicing实现。实现方式部署一个GPU Sharing Scheduler Extender比如阿里开源的gpushare-scheduler-extender。它的原理是把一张GPU按显存切成若干份通过调度器扩展器来分配但实际上这些“份”还是共享同一个GPU核心只是限制了显存使用。优点是灵活缺点是一旦某个容器跑满GPU核心其他容器就会卡成PPT。经验之谈推理场景用时间片共享效果不错训练场景慎用除非你愿意接受“慢就是快”的结果。三、DRADynamic Resource AllocationK8s 1.34的“亲儿子”K8s v1.34引入的DRA动态资源分配是专门为解决GPU这类异构资源设计的。相比Device PluginDRA最大的改进是支持更细粒度的资源描述和跨Pod共享。声明一个ResourceClaimTemplate比如一张支持MIG的GPUapiVersion:resource.k8s.io/v1kind:ResourceClaimTemplatemetadata:name:gpu-templatespec:spec:devices:requests:-name:my-gpudeviceClassName:nvidia.com-migrequest:count:1parameters:apiVersion:nvidia.com/v1kind:MIGParametersspec:gpuInstanceSize:1g.5gb然后在Pod中直接引用这个ClaimapiVersion:v1kind:Podmetadata:name:my-podspec:containers:-name:mainimage:nvidia/cuda:12.0-baseresources:claims:-name:gpuresourceClaims:-name:gpusource:resourceClaimTemplateName:gpu-template对比Device PluginDRA允许你在Pod级别就定义好GPU实例大小并且支持多个容器共享同一个Claim这在多容器推理场景如sidecar 主容器下非常有用。四、运维实战DCGM Prometheus Grafana没有监控的GPU调度就是盲人摸象。**DCGMData Center GPU Manager**是NVIDIA官方的监控工具配合Prometheus可以让你对每张GPU的健康状况了如指掌。部署DCGM Exporterhelm repoaddgpu-helm-charts https://nvidia.github.io/dcgm-exporter/helm-charts helminstalldcgm-exporter gpu-helm-charts/dcgm-exporter关键指标DCGM_FI_DEV_GPU_UTILGPU核心利用率别只看这个很多人以为高了就好其实高可能意味着效率高也可能是死循环DCGM_FI_DEV_MEM_COPY_UTIL内存带宽利用率推理场景这个指标更关键DCGM_FI_DEV_POWER_USAGE功耗突然掉功耗可能是卡挂了DCGM_FI_DEV_ECC_SBE单比特ECC错误如果持续增长说明卡快不行了五、高级玩法自定义调度器插件实现“空闲资源抢占”前面提到GPU浪费的一大原因是低优先级任务占着茅坑不拉屎。我们可以通过编写Kubernetes调度插件来解决这个问题。思路在PostFilter阶段检查所有pending的高优先级任务如果发现某个节点GPU利用率低于阈值比如10%就直接抢占该节点上的低优先级Pod。代码片段伪代码func(p*ReclaimIdleResource)PostFilter(ctx context.Context,state*framework.CycleState,pod*v1.Pod,filteredNodeStatusMap framework.NodeToStatusMap)(*framework.PostFilterResult,*framework.Status){for_,node:rangeallNodes{// 检查节点上是否有低优先级且利用率低的Podfor_,podOnNode:rangenode.Pods{ifpodOnNode.Prioritypod.Priority{// 通过DCGM获取GPU利用率gpuUtil:getGPUUtilization(podOnNode)ifgpuUtil10.0{// 驱逐这个PodevictPod(podOnNode)returnframework.PostFilterResult{NodeName:node.Name},framework.NewStatus(framework.Success)}}}}returnnil,framework.NewStatus(framework.Unschedulable)}这个功能目前在阿里、字节等大厂内部已经落地开源版本可以参考Scheduler Plugins项目中的NodeResourceManager。六、最后的忠告GPU调度不是纯技术问题它涉及组织管理。我见过最成功的团队是这样做的分级资源池训练池独占卡、推理池共享卡、开发测试池MIG小卡。成本透明每个团队能看到自己消耗了多少GPU小时财务上内部结算。自动化回收闲置30分钟的任务自动驱逐并通知owner。只有技术流程文化三者结合才能真正让GPU利用率突破天花板。