Kubernetes DRA 优先设备列表怎么落地：H100 不可用时自动回退 A100

GPU节点资源紧张的时候，不少集群都得在调度器之外额外写一层脚本，逻辑就是先找空闲的H100，找不到再退而求其次用A100。Kubernetes v1.36推出的Dynamic Resource Allocation（DRA），直接把这类设备偏好逻辑内置到了设备请求里：用优先列表声明好有序的候选设备，H100没有剩余可用资源时自动尝试分配A100，整套调度逻辑和ResourceClaim完全跑在Kubernetes原生资源模型里，不需要额外外挂编排。

H100优先、无可用时自动回退A100的DRA配置，本质是把散落在各处的自定义调度收敛到原生Kubernetes资源模型里，不需要再在外围堆大量优先级判断脚本。

这次DRA更新，解决的就是“设备型号写死”的老问题

传统GPU调度方案，经常把型号硬编码到节点标签或者自定义脚本里。集群设备品类单一的时候还能正常跑，一旦节点池里同时混存H100、A100，还有处于维护状态的故障卡，业务方就得自己维护一套优先级、重试和失败提示逻辑。这些优先级逻辑散落在Helm values、队列服务和运维脚本各处，到最后甚至答不出一个简单的问题：这次Pod为什么最终拿到的是A100而不是H100？

Kubernetes官方在v1.36的DRA更新中把优先列表特性升至稳定版，专门用“优先选H100、没有时回退A100”作为典型使用场景做说明。这个能力的价值不是凭空多出可用GPU，而是把“先试哪个、再试哪个”的规则变成调度请求本身的一部分，大幅减少外围自定义编排代码量。

先分清三种核心语义：优先级、健康度和容量

把H100排在候选列表第一行，不代表调度器会自动帮你判断所有业务兼容性。DRA请求至少涉及三层判断逻辑，混为一谈最容易出现“YAML写的没问题，任务就是跑不起来”的意外。

尤其要注意“设备健康”和“优先级”是完全独立的两套逻辑。某张H100就算型号完全匹配，如果驱动上报它处于不健康状态，也不该因为它排在优先级第一位就强行绑定。v1.36同步迭代了资源健康状态相关能力，运维侧最好把Pod状态、DRA驱动事件和节点日志放在同一张校验清单里统一排查。

最简请求怎么写才能实现H100到A100的回退

下面的YAML只展示基础请求思路，具体API版本、驱动名称和属性键值必须以你实际用的DRA驱动官方文档为准。核心不是照抄字段，而是把候选设备放入带明确顺序的列表，同时给每个候选标注好可校验的属性。

apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
  name: training-gpu
spec:
  devices:
    requests:
      - name: accelerator
        exactly:
          deviceClassName: gpu.example.com
          selectors:
            - cel:
                # 先尝试 H100，再尝试 A100
                expression: device.attributes["model"] == "H100"
            - cel:
                expression: device.attributes["model"] == "A100"

示例里用两条候选声明表达优先关系，实际用的驱动可能要求使用专门的优先列表结构或者不同的CEL属性路径。落地的时候别只改个型号字符串就完事：先确认驱动暴露的属性名、候选顺序语义和API版本，再去测试集群查看ResourceClaim、ResourceSlice以及Pod事件反馈。

四个场景就能把回退逻辑验透

只测“集群有H100时Pod能拿到H100”远远不够，这只能证明首选路径通。建议给每个测试场景留存对应的Claim状态、Pod调度事件和驱动日志，这些记录比“Pod最终变成Running状态”更有参考价值。

1. 首选可用：H100和A100都处于空闲状态，确认最终绑定的是H100，同时记录实际分配到的设备属性。
2. 首选耗尽：临时把所有H100占满，确认请求会按顺序尝试分配A100，而不是长时间卡在Pending状态或者随机选设备。
3. 两者都不可用：确认事件能明确说明所有候选设备都不满足要求，上层队列系统能识别出“资源不足”状态，不会无限循环重试。
4. 首选不健康：模拟驱动上报H100状态为unhealthy，确认这台设备不会因为型号优先级高就被强行绑定。

生产环境还要额外加一项“后备设备能否承载同一镜像”的验证。H100和A100的显存上限、驱动版本、算子支持范围以及性能基线不一定完全相同。如果业务训练任务只能在H100上完成，正确的做法是把H100声明为硬约束，别把A100伪装成安全的回退选项。

DRA和节点标签、Device Plugin的权责边界

DRA上线不会让你现有的Device Plugin立马失效。官方给出的迭代方向是逐步从传统Device Plugin迁移到DRA；过渡期你完全可以继续跑旧工作负载，同时让新任务使用ResourceClaim。团队需要先确认当前GPU驱动版本是否已经支持DRA，再决定是双轨并行还是统一迁移。

• 节点标签适合表达粗粒度归属，比如节点池、地域或者运行环境，不适合承载多级设备偏好逻辑。
• Device Plugin大概率还是你当前集群的GPU暴露方式，迁移前必须核对驱动、监控和资源命名规则。
• DRA设备污点可以把故障卡或者专用卡隔离出来，但Pod侧还是需要配置对应的容忍规则才能匹配。
• ResourceClaim的生命周期要纳入队列清理和失败恢复流程，不然就算请求逻辑完全正确，也可能被残留的旧Claim占住资源。

上线前的最小检查清单

一次稳妥的DRA试点，至少要在变更评审里覆盖下面这些问题：

• 当前实际使用的驱动支持哪个版本的DRA API、哪个deviceClassName和哪些属性字段？
• 候选列表的顺序是否真的表示按优先级尝试，而非同时匹配所有选项？
• H100回退到A100之后，镜像、CUDA版本、显存和核心算子是否全部通过测试？
• 设备处于非健康状态、被打了污点、驱动重启时，Pod事件和告警能不能清晰说明故障原因？
• ResourceClaim绑定失败后，上层队列会不会自动释放资源或者重试，有没有设置最大重试次数？

常见问题

优先列表会让H100和A100同时分配吗？

不会。它表达的是有序候选关系，目标是按顺序尝试首选设备；最终绑定行为仍受DRA驱动和请求结构约束，需要用调度事件和实际设备属性校验结果。

没有H100的时候，所有任务都适合自动回退到A100吗？

不适合。只有在显存、驱动、算子和性能目标全部满足要求的情况下才允许回退；不能接受性能降级的训练任务，应该直接把H100作为硬约束条件。

设备健康状态能完全代替故障卡隔离吗？

不能完全代替。健康状态只能识别当前暴露的设备问题，设备污点、维护流程和驱动告警还是要同步配合，避免故障卡反复进入候选分配池。

已经用了Device Plugin的集群必须马上迁移吗？

不用马上全量迁移。先确认现有GPU驱动是否支持DRA，选一类可以快速回归的小范围任务做双轨验证，再根据监控、队列和回滚能力的成熟度决定最终迁移范围。

把“可回退”变成可追溯的调度规则

Kubernetes v1.36的DRA优先列表值得关注，核心原因是它把异构GPU集群里非常普遍的设备偏好需求，变成了原生资源请求的一部分。真正落地上线的时候，重点不只是写出H100→A100的优先顺序，还要同步验证健康状态校验、驱动属性匹配、工作负载兼容和失败资源释放全链路都能正常闭环。先在测试集群跑完四个核心场景，再把回退策略同步到生产队列，通常比在外围脚本里不停堆叠判断逻辑要好维护得多。