权威消息显示，前面两篇：Kubernetes 官方出品：一个 Controller 搞定 Job 排队和资源配额 和 终于搞懂 Kueue：5 个核心对象一次讲透 把 Kueue 的基本玩法和核心对象走了一遍，不过 Demo 都跑在 CPU 上。 科技新闻。
容器里再通过同一个 gpu-claim 关联到这次申请到的设备：
再看 Workload 状态，就能发现为什么第二个 Job 一直起不来：
ue背景与起因
集群起来后确认版本：
这两个名字最容易看混：
Kueue 能不能管理 DRA 模式下的 GPU？
ue事件经过
修改 Kueue manager config 后，需要重启 kueue-controller-manager 让新配置生效。
本文不展开 extended resource 路径，避免把两种 DRA 接入方式混在一起。
所以完整关系是：ResourceClaimTemplate(single-gpu) -> Pod resourceClaims(gpu-claim) -> container resources.claims(gpu-claim)。
ue各方回应
这里要注意一点：Kueue 只是负责“准入”，真正把 GPU 分配给 Pod 的还是 kube-scheduler 和 DRA Driver。
再确认节点能看到 GPU：
这次只用一个队列，GPU 配额只给 1 张 T4。这样后面再提交第二个 Job 时，Pending 状态会看得很清楚。
ue影响分析
再看 DeviceClass：
如果测试自然环境访问 registry.k8s.io 不稳定，也可以用 GitHub Release 里的 chart 包：
这里 Kueue 做的事情很直接：读取 Workload 引用的 ResourceClaimTemplate，识别里面的 deviceClassName 和 count，再通过 deviceClassMappings 折算成 ClusterQueue 里的配额资源。
ResourceClaim 已经分配：
后面的 Job 会直接引用 gpu.nvidia.com 这个 DeviceClass，实际可分配设备则来自这些 ResourceSlice。
DRA 和 Kueue 使用的资源名称并不是同一个。ResourceClaimTemplate 里写的是 deviceClassName: gpu.nvidia.com，而 ClusterQueue 里扣配额用的是资源名，所以这里需要做一次映射：
这段配置的意思是：只要 Workload 通过 ResourceClaimTemplate 申请 gpu.nvidia.com 这个 DeviceClass，Kueue 就把它折算成 nvidia.com/gpu 这个逻辑资源来扣配额。
安装完成后，确认 GPU Operator 组件正常运行：
集群使用 KubeClipper 创建。KubeClipper 1.6.0 默认支持 Kubernetes 1.36.1、containerd 2.2.4，和本文生态环境一致，详细步骤可以参考：KubeClipper 1.6.0 发布：kcctl 优化与 K8s 1.36 支持。
再看看 ClusterQueue，可以发现 GPU 配额已经被扣掉了：
Pod 里这段不是重新定义一个模板，而是引用已经存在的 single-gpu 模板：
真到 GPU 集群里，大家更关心的是另一个情况：
安装完成后，先看 DRA Driver 组件：
两者靠 Kueue 配置里的 deviceClassMappings 关联起来。少了这段映射，Workload 会被标成 Inadmissible，原因类似：
--set devicePlugin.enabled=false：关闭 DevicePlugin，避免与后续安装的 DRA Driver 冲突。
这说明 deviceClassMappings 已经生效：用户写的是 ResourceClaimTemplate，Kueue 扣的是 nvidia.com/gpu 这个逻辑配额。
Kueue 使用 0.18.1，安装方式和前两篇一样：
再提交 Kueue 管理的 Job：
GPU Driver、NVIDIA Container Toolkit 等基础组件使用 GPU Operator 安装。完整说明可以参考之前这篇：GPU 环境搭建指南：使用 GPU Operator 加速 Kubernetes GPU 环境搭建。
队列里只有 1 张 GPU 配额。如果再提交一个同样申请 single-gpu 的 Job：
注意这里的 coveredResources 里包含 nvidia.com/gpu。这是映射后的逻辑资源名，不是 Pod 里直接写的扩展资源。
Job 被 Kueue 准入后，会从 Suspended 变成 Running：
直接看 Workload 的准入结果：
本文后面会安装 NVIDIA DRA Driver，所以安装 GPU Operator 时需要关闭 DevicePlugin：
这里有两个细节容易混：
ResourceClaimTemplate 里写的是：
对 DRA 不熟悉的同学，可以先看这篇：DRA P1：DRA 能解决什么问题？从部署到使用的完整体验
所以生产环境里建议同时关注 ResourceClaim 状态和 Pod 状态。如果希望 Workload 在 Pod 长时间起不来时释放 Kueue 配额，可以结合 waitForPodsReady 做保护。
整卡调度用的是 gpu.nvidia.com。对应的 ResourceSlice 里能看到节点上的 T4：
使用 DRA 之后，Job 不再写 resources.limits.nvidia.com/gpu: 1，而是引用一个独立的 ResourceClaimTemplate。
到这里可以看到，Kueue 并没有直接参与 GPU 分配，而是站在 Job 准入这一层，通过 deviceClassMappings 把 DRA 的设备申请转换成队列里的配额资源。这样既保留了 DRA 的设备模型，也让 GPU 可以继续纳入 Kueue 的统一配额管理。
快速创建单节点集群的命令如下：
ClusterQueue 里写的是：
先创建 ResourceClaimTemplate：
最后安装 NVIDIA DRA Driver 25.12.0：
容器里能看到 T4：
环境准备分几段走：先创建 K8s 集群，再用 GPU Operator 把 GPU Driver / Container Runtime 准备好，最后装 Kueue 和 NVIDIA DRA Driver。
这一篇就把它跑通。NVIDIA DRA Driver 负责把整卡 GPU 发布成 DeviceClass / ResourceSlice，Kueue 在 Job 准入阶段读取 DRA 设备申请，判断这个 Job 能不能进入队列。
下一篇继续往前走一步，把 HAMi 引入进来：一张 GPU 被切成多份 vGPU 之后，Kueue 是否还能继续管理显存和算力配额，后续进展有待观察。