系统设计面试：如何为 Kubernetes DRA 设计可解释的设备优先级与回退？

题干与适用场景

你负责一个运行训练与推理作业的 Kubernetes 集群。节点上同时存在 H100、A100 和较小的加速器，业务希望同一个 Pod 优先使用 H100，资源不足时按声明顺序回退到 A100，再回退到其他兼容设备。请设计基于 Dynamic Resource Allocation（DRA）的设备请求与调度方案，并说明确定性、公平性、故障处理、可观测性、迁移和回滚。回答应面向能参与架构取舍的高级工程师。

面试官考察点

能否把“优先级”定义成可验证的约束，而不是在客户端硬编码抢占。
能否解释 ResourceClaim、ResourceSlice 与调度器之间的生命周期。
能否处理同一优先级下的确定性并列、设备健康、重试和超时。
能否同时讨论容量公平、租户隔离、指标和审计。
能否给出从设备插件迁移到 DRA 的灰度与回滚边界。

回答前需要澄清的问题

回退是“任一可用设备即可”，还是必须保持显存、架构和驱动能力等硬约束？
一个 Pod 可接受多张不同型号设备吗？拓扑、NUMA 和网络带宽是否是硬约束？
业务需要严格的设备型号承诺，还是允许在成功率与成本之间优化？
租户是否有配额、优先级和抢占规则？故障中的设备是否立即从候选集中移除？
现有工作负载能否改成 ResourceClaim，迁移期间是否必须与旧设备插件共存？

30 秒回答

我会把设备偏好编码为带有硬约束和有序候选的 DRA 请求，由调度器在资源声明阶段完成匹配，而不是让客户端轮询节点。调度器先过滤驱动、架构、拓扑和租户配额等硬约束，再按 H100、A100、其他兼容设备的顺序选择。每一层都使用稳定的确定性并列规则，并把候选、拒绝原因和最终选择写入事件与指标。设备健康变化或绑定失败时只在声明仍可重试的范围内重新评估；公平性通过队列配额和租户权重保证。迁移采用双轨灰度、可逆的 ResourceClaim 模板和旧插件回滚开关。

分步骤深入解答

1. 定义偏好模型

把型号顺序作为软偏好，把驱动版本、架构、显存下限、拓扑和安全隔离作为硬约束。示例请求可表达“首选 H100，次选 A100”，但不能让回退绕过显存或租户配额。请求还应包含版本化的策略标识，便于审计和回滚。

yaml

apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
spec:
  spec:
    devices:
      requests:
      - name: accelerator
        exactly:
          deviceClassName: gpu
          selectors:
          - cel: "device.attributes['model'] == 'H100'"
          - cel: "device.attributes['model'] == 'A100'"

这里的有序选择表达业务偏好；实际部署仍要以集群支持的 DRA API 版本和驱动能力为准。

2. 资源声明与调度流程

Pod 通过 ResourceClaimTemplate 生成声明。DRA 驱动发布 ResourceSlice，描述设备属性、容量和健康状态。调度器在预选阶段读取声明与切片，先验证硬约束，再按候选顺序寻找可绑定设备；绑定成功后，驱动将分配结果注入容器。声明必须是幂等的，重试不能产生第二份不可回收的分配。

3. 确定性选择与解释

同一候选层有多台设备时，使用资源池、ResourceSlice 名称和设备标识的稳定字典序，或显式的容量与拓扑排序；规则必须写入接口契约。每次调度记录候选列表、过滤条件、拒绝原因、最终设备和策略版本。这样重放同一输入可以得到相同结果，排查“为什么没有拿到 H100”时也有证据。

4. 故障、健康与重试

健康状态不可用时，新声明应跳过该设备；已绑定任务则由运行时和控制器决定是否终止、迁移或重建。绑定冲突、切片过期和节点下线要区分为可重试与不可重试错误。重试需带退避和声明幂等键，避免高峰期反复扫描放大调度负载。回退到 A100 只能在硬约束仍满足时发生，并应在 Pod 状态中显式显示实际型号。

5. 公平性、容量与可观测性

优先级不应变成无限期占用 H100 的通行证。队列层按租户配额、权重和等待时间进行公平仲裁，设备层按候选顺序选择。核心指标包括各型号请求量、回退率、等待时间、绑定失败率、健康变化、每租户占用量和策略命中率。事件中保留可读的选择链路，日志避免泄露租户敏感数据。

6. 迁移与回滚

先为少量工作负载提供 DRA 类和 ResourceClaim 模板，旧设备插件继续服务未迁移的 Pod。对比成功率、回退率、调度延迟和 GPU 利用率后扩大范围。模板和策略版本化；发现驱动或调度问题时，停止新模板发布并把工作负载切回旧插件，已绑定任务按既定终止策略处理，避免同时修改声明和底层设备分配。

高质量示范回答

我会把问题拆成偏好、约束和分配证明三层。偏好是有序候选，约束包含型号能力、显存、驱动、拓扑、租户配额和安全边界。Pod 创建后通过 ResourceClaim 请求设备，DRA 驱动发布 ResourceSlice，调度器先过滤硬约束，再按候选顺序选择；同层采用稳定的资源池与设备标识排序，保证重放一致。每次选择都写入事件，包含候选、拒绝原因、策略版本和实际型号。

故障路径要区分健康不可用、绑定冲突、声明过期和节点下线。只有可重试错误才退避重试，回退不能越过硬约束，最终型号必须回写状态。公平性由租户配额、队列权重和等待时间控制，避免 H100 偏好压垮低优先级租户。迁移采用旧插件与 DRA 双轨灰度，模板可回滚，指标达到门槛后再扩大范围。

常见错误

只说“按型号排序”，没有定义硬约束和同层并列规则。
让客户端扫描节点或直接抢占设备，绕开声明与调度器。
把设备健康、绑定冲突和不可满足约束都当成无限重试。
只追求 H100 命中率，忽略租户公平、配额和等待时间。
迁移时一次性删除旧设备插件，导致无法快速回滚。
只记录最终设备，不记录候选与拒绝原因，无法解释回退。

追问及应对

如果 H100 和 A100 都满足约束，为什么不随机选择？

随机会降低重放能力和调试质量。可以在稳定排序后加入容量均衡，但必须保持规则可解释、输入可观测，并避免把随机种子当成隐藏契约。

设备在预选后、绑定前变成不健康怎么办？

绑定阶段再次校验版本和健康状态；失败时返回分类错误，只有声明仍有效且有候选时才退避重试，否则让 Pod 暴露明确的不可满足原因。

如何证明回退没有破坏公平性？

按租户和型号统计等待时间、占用量、回退率和队列份额，进行离线重放与线上灰度对比。若某租户长期拿不到首选设备，应调整配额或权重，而不是继续提高其请求优先级。