代表性面试主题

系统设计面试:如何用 Kubernetes v1.36 DRA 管理 Node Allocatable 资源?

系统设计困难
Offer.cc 编辑团队发布 更新

题干

DRA 驱动为加速卡分配资源时还会消耗 CPU、内存或 hugepages。请设计一套 Node Allocatable 资源治理方案,避免 DRA 资源与普通 Pod 请求重复计数或超卖。

题目与适用场景

一个多租户推理集群通过 Dynamic Resource Allocation(DRA)分配加速卡。驱动为每个设备申请一份 CPU、内存或 hugepages,且部分设备需要 NUMA 对齐。请设计 Kubernetes v1.36 的 Node Allocatable 资源方案:让调度器同时考虑 DRA 分配和普通 Pod 请求,解释 ResourceSlice 映射、Pod status、灰度、监控与回滚边界。

官方 v1.36 DRA 更新把 Node Allocatable 资源作为第一轮能力,支持把 DRA 管理的 CPU、内存和 hugepages 纳入标准节点账本;该能力仍属 alpha,应按实验性特性设计发布护栏。

背景与边界

本题只讨论调度前的资源会计、拓扑约束和发布安全。设备驱动如何实现硬件分配、业务如何容错属于外部依赖;回答应明确 API 版本、feature gate、容量新鲜度、账本一致性和回滚条件。

面试官考察点

  • 能否从资源账本、调度器、DRA driver、ResourceSlice 和 Pod status 画出闭环。
  • 能否区分设备容量、设备分配带来的节点资源占用和普通 Pod request,避免双计费。
  • 能否处理 NUMA、hugepages、节点更新乱序、驱动重启和 ResourceSlice 陈旧数据。
  • 能否为 alpha feature gate 设计灰度、观测、回滚和兼容旧 driver 的路径。
  • 能否把状态更新权限限制在 DRA 合成子资源和节点范围内。

30 秒回答框架

“我会让 DRA driver 在 ResourceSlice 的 nodeAllocatableResourceMappings 中声明每种设备对 CPU、内存或 hugepages 的映射。调度器把已分配 claim 的映射与普通 Pod requests 合并到节点账本,设备本身只计入一次。映射支持 allocationMultiplier,必要时用 capacityKey 表示消耗容量;Pod status 的 nodeAllocatableResourceClaimStatuses 记录实际分配结果。上线先在少量节点开启 DRANodeAllocatableResources,验证 NUMA、乱序更新和 pending 行为,异常时停止新 claim 并回退 driver 映射。”

分步骤深入解答

  1. 定义资源模型。 将设备 ID、ResourceClaim、节点、NUMA 区域、资源名称、单位、映射版本和观察时间放入可重放账本。区分设备容量与其占用的 CPU、内存、hugepages;同一 claim 的占用只能进入账本一次。
  1. 发布 ResourceSlice 映射。 DRA driver 在 ResourceSlice 中填写 nodeAllocatableResourceMappings。映射键可以是 CPU、memory、ephemeral-storage 或 hugepages;每个设备的固定占用可用 allocationMultiplier 表达,按容量消耗的资源可用 capacityKey 表达。
yaml
resourceSlice:
  nodeAllocatableResourceMappings:
    cpu:
      allocationMultiplier: 2
    memory:
      allocationMultiplier: 4Gi
    hugepages-2Mi:
      capacityKey: consumed

上例只表达映射语义;字段类型和单位必须以当前 Kubernetes API schema 及 driver 实现为准,不能把示意 YAML 直接当作可提交对象。

  1. 合并调度账本。 调度器读取 ResourceSlice 和已绑定 ResourceClaim,计算 DRA 贡献,再叠加普通 Pod request。对同一 claim 使用稳定分配键去重;ResourceSlice 版本落后或映射缺失时,让 Pod pending 并告警,不要用旧容量继续放行。
  1. 处理 NUMA 与更新顺序。 映射记录 NUMA 亲和性和版本。只有同一节点的分配、释放和 ResourceSlice 版本满足单调条件才提交账本;驱动重启时先重建映射,再恢复新 claim,避免短暂重复占用。
  1. 暴露状态与观测。 Pod 的 status.nodeAllocatableResourceClaimStatuses 记录 claim 对节点资源的实际状态。监控账本容量、已用量、映射年龄、pending 原因、重复计数拒绝次数和 NUMA 放置失败率,并把状态更新与调度决定关联到 claim UID。
  1. 灰度与回滚。 在控制面、调度器和 driver 兼容后,只对 canary 节点开启 DRANodeAllocatableResources。先验证 ResourceSlice、普通 Pod 与 claim 混排、节点重启、驱动升级和回收;异常时停止新 claim,保留已有绑定,导出账本并修复映射,再按版本恢复。alpha 能力不得默认假设所有集群都可安全开启。
  1. 安全边界。 DRA driver 只获得完成自身状态更新所需的合成子资源权限;节点本地 driver 使用节点感知的 verbs 和最小 RBAC。状态写入失败应告警并重试,不能通过扩大权限绕过账本不一致。

高质量示范回答

我会把 Node Allocatable 当成一个有版本的资源账本。driver 在 ResourceSlice 的 nodeAllocatableResourceMappings 声明设备对 CPU、内存或 hugepages 的贡献,固定贡献用 allocationMultiplier,按容量消耗的贡献用 capacityKey。调度器读取已绑定 claim,把每个 claim 的贡献与普通 Pod request 合并,使用 claim UID 去重,避免设备占用和节点资源占用被重复计算。

账本必须记录节点、设备、NUMA、映射版本和观察时间。ResourceSlice 过期、版本倒退或 driver 重启重建期间,宁可让新 Pod pending,也不能依据旧容量放行。Pod 的 nodeAllocatableResourceClaimStatuses 用于回读分配结果和诊断,不能替代账本一致性检查。

因为 v1.36 仍是 alpha,我会先在 canary 节点开启 DRANodeAllocatableResources,验证 claim 与普通 Pod 混排、NUMA、节点重启、释放和 driver 升级。回滚时停止新 claim,保留已有绑定并导出账本;修复映射后再恢复。RBAC 只授予 DRA 合成子资源和节点范围权限。

常见错误

  • 错误表现: 每个设备都直接扣一次节点 CPU,claim 重试后再扣一次 → 失败原因: 缺少稳定幂等键 → 修正方法: 以 claim UID、设备 ID 和映射版本去重。
  • 错误表现: 把示意 YAML 当作正式 API 对象提交 → 失败原因: 映射字段的 schema 与单位需要按版本核对 → 修正方法: 以 ResourceSlice API 定义和 driver 版本验证。
  • 错误表现: ResourceSlice 暂时失联仍沿用旧容量 → 失败原因: 陈旧数据会造成超卖 → 修正方法: 设置 freshness 窗口,超时让新 claim pending。
  • 错误表现: alpha gate 一次性全量开启 → 失败原因: 兼容性和回滚面未验证 → 修正方法: canary、指标、停止新 claim 和可恢复账本。
  • 错误表现: 用扩大 RBAC 解决状态写入失败 → 失败原因: 权限越界且无法消除数据一致性问题 → 修正方法: 使用合成子资源、节点感知 verbs 和审计日志。

追问及应对

allocationMultipliercapacityKey 怎么选?

设备每次分配都消耗固定 CPU 或内存时使用 allocationMultiplier。资源消耗随设备容量或工作负载变化时使用 capacityKey,并让 driver 提供可审计的容量语义;两者都要在 schema、单位和版本中固定。

普通 Pod request 与 DRA 映射如何避免重复?

建立单一账本:普通 Pod request 进入 request 流,DRA 贡献按 claim UID 进入 allocation 流,调度汇总时只对每个 claim 应用一次映射。账本应记录来源和版本,出现重复键时拒绝放行并告警。

driver 重启时是否立即恢复调度?

不立即恢复。先重建 ResourceSlice、校验已绑定 claim、确认版本单调和容量一致,再恢复新 claim;重建窗口内只保留已有绑定并让新 Pod pending。

如何证明 NUMA 放置没有破坏资源账本?

回放跨 NUMA、同 NUMA、释放重试和节点重启事件,比较节点总账、NUMA 子账和 Pod status。指标包括放置失败率、账本差异、pending 时长和重复计数拒绝次数。

何时可以从 alpha 推广?

至少要有兼容 driver 覆盖、回滚演练、节点重启和升级回放、账本差异为零的观察窗口,以及明确的容量和 pending SLO。不能仅凭构建通过或单节点成功就全量开启。

参考资料

  • Kubernetes v1.36 DRA 更新(Kubernetes Blog)
  • Feature Gates(Kubernetes Documentation)
  • ResourceSlice API(Kubernetes Documentation)
  • Pod API(Kubernetes Documentation)
  • DRA hardening guide(Kubernetes Documentation)

面试作答要点

先画出 driver、ResourceSlice、claim、调度器、Node Allocatable 账本和 Pod status 的数据流,再补幂等、版本、NUMA、灰度和最小权限。

一句话总结

DRA Node Allocatable 的核心是把 claim 对节点资源的真实贡献纳入单一、有版本、可回滚的调度账本。

继续练习

把资源映射扩展到多节点 ResourceClaim,并说明跨节点拓扑、容量新鲜度和故障恢复如何改变调度决策。

公开来源

同类题目

相关面试工具

用 Solve 整理系统设计回答

从澄清需求开始,展开规模、架构、组件选择和取舍。

查看工具