Kubernetes动态资源分配支持异构加速器

我第一次把这条消息放进升级清单时，差点把它理解成“安装一个新组件，就能自动调度所有 GPU”。实际情况更准确：CNCF 在 2026 年 11 月 10 日的公告中，把 Kubernetes 的工作负载感知调度和 Dynamic Resource Allocation（DRA）列为 AI 基础设施进展；同时，HAMi 进入孵化阶段，负责异构加速器的共享与调度。它们属于同一生态方向，却不是同一个功能开关。

官方地址：https://kubernetes.io/

如果你的集群要混用不同型号 GPU、FPGA 或其他专用设备，DRA 的价值是把“设备属性、可用状态和工作负载声明”拆成可组合对象，让调度器按条件选设备；它不是把旧的设备插件请求语法原样升级，也不会自动替你安装厂商驱动。

这次生态消息到底改变了什么

CNCF 公告提到 Kubernetes 在工作负载感知调度和 DRA 上取得进展，并把 HAMi 的异构加速器共享与调度能力放在同一组 AI 基础设施成果中。对平台团队来说，真正值得关注的是调度模型正在从“节点上有几个某型号资源”转向“这个工作负载需要什么设备属性、容量和配置”。

当前 Kubernetes 官方文档把 DRA 标记为从 v1.35 起稳定的能力；Kubernetes v1.37 的官方更新又说明，DRA Extended Resource 已经进入 GA，可以让传统 extended resource 请求与 DRA 设备匹配。迁移时不要只看新闻标题，应该把 Kubernetes 版本、驱动实现和现有请求方式一起列入变更范围。

公告原文：https://www.cncf.io/announcements/2026/11/10/cncf-hits-major-milestones-with-global-community-growth-record-industry-investment-and-a-new-generation-of-projects-to-build-ai-systems-in-production/

从设备插件到 DRA，几个对象分别负责什么

旧方案通常把设备插件暴露的资源名直接写进 Pod 的 resources.limits。DRA 则把设备目录、筛选条件、申请关系和 Pod 使用关系拆开：

异构设备请求不应只写一个厂商资源名

当工作负载只需要“支持某种计算能力、显存范围和互联属性”的设备时，DRA 可以用结构化参数和 CEL 表达式筛选设备。下面是一个用于说明对象关系的简化 YAML，字段含义应以目标 Kubernetes 版本及设备驱动文档为准；它不是已经在某个集群执行过的结果。

apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
  name: inference-accelerator
spec:
  devices:
    requests:
    - name: primary
      exactly:
        deviceClassName: accelerator.example.com
        # 用属性表达需求，避免把某个厂商型号写死在业务 Pod 中。
        selectors:
        - cel:
            expression: device.attributes["accelerator.example.com"].memoryGiB >= 24
---
apiVersion: v1
kind: Pod
metadata:
  name: inference-worker
spec:
  containers:
  - name: worker
    image: example/inference-worker:stable
    # 容器通过 ResourceClaim 使用已分配设备，不直接猜测节点名称。
    resources:
      claims:
      - name: primary
  resourceClaims:
  - name: primary
    resourceClaimName: inference-accelerator

这段示例有两个重点：一是把设备选择条件放到 Claim 中，二是让 Pod 引用 Claim，而不是用节点名把调度器绕开。真实落地前要检查设备驱动提供的属性名称、API 版本和字段结构，不能把示例中的域名当成现成驱动。

升级前最容易忽略的四个风险

1. 版本和驱动不是一回事。DRA API 进入稳定状态，不代表每个厂商驱动都已经支持相同的 DeviceClass、ResourceSlice 或状态字段。先确认控制面版本、节点组件版本和驱动支持矩阵。
2. 预绑定 Pod 会绕过正常调度。如果直接设置 spec.nodeName，Pod 可能在 Claim 尚未分配时就被送到节点，最终由 kubelet 反复检查。要固定节点，优先使用能继续经过调度流程的节点选择器。
3. DRA 资源目前不能按普通 Pod 资源抢占。官方文档明确提示，正在使用 DRA 设备的 Pod 不能被更高优先级的 Pod 通过抢占直接赶走；容量紧张时要把等待和释放时间纳入队列设计。
4. 旧监控指标可能不覆盖新对象。以前只看节点扩展资源数量，迁移后还要观察 ResourceClaim 状态、ResourceSlice 信息和设备健康状态，否则会出现“节点看起来有资源、Claim 却无法分配”的盲区。

我会这样安排一轮灰度迁移

1. 先盘点现有设备插件、扩展资源名、节点标签、容器运行时和驱动版本，记录哪些业务真的依赖设备型号，哪些只依赖显存或架构能力。
2. 在非生产节点安装支持 DRA 的驱动并观察 ResourceSlice 是否能描述预期设备；这一步只做资源目录和状态检查，不把业务流量切过去。
3. 为一类低风险工作负载创建独立 ResourceClaim，验证 Claim 的分配、Pod 调度、设备注入和释放是否闭环。
4. 把调度结果、Claim 状态、设备健康、Pod 重启和等待时长纳入同一张回归表，尤其记录设备不可用时的失败原因。
5. 只有在灰度完成后，才考虑启用 DRA Extended Resource 或把旧请求逐批迁移；保留回滚路径，不要一次性删除旧设备插件。

我个人更倾向于先让 DRA 管理“属性复杂、型号混杂”的工作负载，继续让简单、成熟的单型号业务使用原有方式。这样能把迁移收益和故障半径控制在可解释范围内。

迁移清单：先确认能不能迁，再决定要不要迁

• 控制面和节点版本是否满足目标 DRA 能力，Feature Gate 或 API 组是否按目标版本处理。
• 设备驱动是否支持 DRA，并能发布准确的设备属性、容量和健康状态。
• DeviceClass 的筛选条件是否描述了业务真正需要的能力，而不是复制硬件商品名。
• ResourceClaim、ResourceClaimTemplate 和 Pod 的命名空间、生命周期与回收策略是否清楚。
• 是否覆盖设备不足、设备损坏、Claim 删除、Pod 重建、节点维护和调度超时等回归场景。
• 是否保留传统请求方式和回滚窗口，且监控、告警、排队策略已经同步调整。

常见问题

DRA 是不是 HAMi 的替代品？

不是。DRA 是 Kubernetes 的资源分配与调度能力；HAMi 是围绕异构加速器共享和调度的生态项目。二者可以在同一 AI 基础设施版图中出现，职责和安装方式仍需分别阅读官方文档。

用了 DRA 就能自动支持所有 GPU 吗？

不能。还需要兼容的设备驱动、节点上的设备、正确的 DeviceClass/Claim 定义，以及与目标 Kubernetes 版本匹配的控制面配置。

现有 extended resource 请求必须马上改掉吗？

不必。Kubernetes v1.37 的 DRA Extended Resource 已进入 GA，但是否迁移取决于驱动支持、设备模型复杂度和回滚要求。先盘点和灰度，比一次性替换更稳妥。

参考资料：https://kubernetes.io/docs/concepts/resource-management/dynamic-resource-allocation/；https://kubernetes.io/blog/2026/09/03/kubernetes-v1-37-dra-updates/；https://www.cncf.io/announcements/2026/11/10/cncf-hits-major-milestones-with-global-community-growth-record-industry-investment-and-a-new-generation-of-projects-to-build-ai-systems-in-production/