Kubernetes GPU / Device Stack 项目地图

当前上游核验（2026-09-27）

以下 commit 是执行时官方默认分支快照，不代表 release 或整套 GPU 能力的成熟度。src-node-feature-discovery-architecture、src-gpu-operator-architecture、src-k8s-device-plugin-architecture、src-dra-driver-nvidia-gpu-architecture 与 src-hami-architecture 保留 2026-06 的 raw-backed Source 及原始 ASCII 图；相关 KEP 笔记保留 2026-07 的设计/演进语境。当前 DRA 基础能力与扩展阶段分别见 kubernetes-dra-design-deep-dive。

官方依据：NFD 当前介绍、GPU Operator 26.7 DRA 管理路径、NVIDIA Device Plugin README、NVIDIA DRA README 与 HAMi FAQ。通过 NVIDIA/k8s-dra-driver-gpu 查询当前 HEAD 时，GitHub 返回的规范 commit 链接仍位于 kubernetes-sigs/dra-driver-nvidia-gpu，这里采用实际返回的链接。

共存与版本边界：GPU Operator 26.7 文档规定集群使用 GPUCluster 或 ClusterPolicy 之一，不支持两者并存或直接原地迁移；HAMi FAQ 要求避免同一节点上的插件争用同一 GPU resource。上述 NVIDIA DRA 仓库 README 仍区分受支持的 ComputeDomain 与未正式支持、默认关闭的独立 GPU plugin，不能用它推定 Operator 26.7 所管理 driver 的相同默认值。部署判断须绑定具体 release、Helm 配置和 feature gates，不能只看 device-plugin、kubernetes-dra、cdi 或 gpu-sharing 名称。

这页把 src-k8s-gpu-device-plugins-stars 从 star list 整理成 Kubernetes GPU / 异构设备资源层地图。核心结论：LLM serving 的 GPU 底座已经不只是“把 /dev/nvidia0 挂进 Pod”，而是 driver/operator、container runtime、device discovery、DRA/CDI、sharing、scheduler、observability、diagnostics 和 fake device 测试环境的组合。

D1 · GPU Device Stack

DISCOVERY / CAPABILITY
  NFD: NodeFeature / NodeFeatureRule / labels / NodeResourceTopology
    - - published capability: informs placement / operator policy - ->
NODE SOFTWARE LIFECYCLE
  GPU Operator: reconcile selected policy and managed components
  Driver / runtime prerequisites must match the chosen installation path
    ├── configure Path A ──> ClusterPolicy / Device Plugin
    │                        extended resource / kubelet Allocate
    │                        ── env / mounts / optional CDI ──> runtime
    └── configure Path B ──> GPUCluster / DRA driver
                             DeviceClass + ResourceSlice / ResourceClaim
                             scheduler allocation / kubelet NodePrepareResources
                             ── CDI device handoff ──> runtime

Path A OR Path B: alternative GPU Operator management modes
Telemetry / health - - observed state - -> operators / node recovery

图例：实线 ── label ──> 表示有序控制动作、API 调用或节点交接；虚线 - - label - -> 表示发现发布、reconcile、watch/health 反馈及重试。上层发现信号供控制器决策，不表示每次分配都同步调用 NFD。node-feature-discovery 发现能力，gpu-operator 管理组件生命周期；device-plugin / kubernetes-dra 承担各自的 allocation 路径，cdi 位于设备注入和 runtime 交接处，不是第三种 scheduler 或 allocator。

图中的分叉表示选择，不表示把两条 GPU 管理路径同时安装。按 GPU Operator 26.7 文档，ClusterPolicy 与 GPUCluster 不能在同一集群并存，也不支持从 ClusterPolicy/独立 DRA Helm 安装直接原地迁移到 GPUCluster。GPUCluster 不管理 GPU driver，需独立 NVIDIADriver 或预装 driver，并事先准备 CDI-compatible runtime；不能把 ClusterPolicy 的 driver/toolkit 管理默认套到另一条路径。即使脱离 Operator 手动部署，也须确保同一物理设备及资源名有明确分配所有权，避免被不同 allocator 重复分配。

D2 · Device Plugin Allocation

Device plugin ── register endpoint / resource name ──> kubelet
Device plugin - - ListAndWatch: devices / health - -> kubelet device manager
kubelet - - Node status publication - -> API: capacity / allocatable

Pod extended-resource request + observed Node allocatable
  ── scheduler Node fit / bind ──> Pod assigned to Node
  - - Pod watch - -> kubelet
kubelet ── select device IDs / Allocate RPC ──> device plugin
device plugin ── Allocate response: env / mounts / device specs / CDI IDs ──> kubelet
kubelet ── CRI container configuration ──> container runtime
runtime ── apply configured device injection / start ──> workload

Device health change - - ListAndWatch update - -> allocatable update / future scheduling

这是传统 extended-resource 路径：scheduler 先按节点资源数量等条件选 Node，节点侧 kubelet/device plugin 完成具体设备分配与容器配置。NVIDIA 的 device-list strategy 决定 envvar、volume-mounts、CDI annotation 或 CDI CRI 交接方式；不是所有安装都走 CDI。健康设备变为 unhealthy 时，kubelet 减少相应 allocatable，capacity 保持原值；这不等于自动迁移或修复已使用故障设备的容器。参见 Kubernetes Device Plugins 和 NVIDIA plugin 配置。

D3 · Discovery / Operator Control Loops

NFD worker ── scan hardware / OS / local feature sources ──> feature set
feature set - - publish NodeFeature - -> Kubernetes API
NodeFeature / NodeFeatureRule - - watch / evaluate rules - -> NFD master
NFD master ── update labels / configured annotations or resources ──> Node
NFD topology-updater - - publish topology - -> NodeResourceTopology
NFD GC - - observe stale / removed nodes - -> cleanup obsolete NFD objects
Node capability / topology - - consumed state - -> scheduler / operator / policy

Admin ── apply ClusterPolicy OR GPUCluster ──> Kubernetes API
desired policy / operand changes - - watch / enqueue - -> GPU Operator reconcile
GPU Operator ── create / update managed operands ──> DaemonSets / Deployments / config
operand readiness / errors - - observed feedback - -> GPU Operator
GPU Operator ── write conditions / status ──> policy object
retryable error / further change - - requeue - -> GPU Operator reconcile

NFD 的 labels、feature 与 topology 数据是已观测状态，可能受扫描周期、API/watch 延迟或 worker 故障影响；NFD GC 清理过期对象不等于硬件故障恢复。Operator 的 Ready 描述所管理组件状态，不承诺每个 Pod 的 GPU 请求都能满足。分配哪块设备、Prepare 是否成功以及容器内隔离是否生效，仍属于后续路径。NFD 组件与数据对象见 当前 Introduction。

D4 · DRA Resource 生命周期

完整状态所有权、binding conditions、Prepare/checkpoint/CDI 与回收细节见 kubernetes-dra-design-deep-dive；官方流程见 How DRA Works。基础 DRA 自 v1.35 stable，各扩展和厂商 driver 的支持阶段仍须分别核验。

Sharing / Isolation Overlay

hami 的经典路径横跨调度、分配交接和容器隔离：scheduler/extender 根据节点设备视图计算 memory/core/count 与设备 reservation，再写 Pod allocation annotations；device-plugin 在 kubelet Allocate 时读取这些信息并返回设备、环境与挂载配置；HAMi-core 在容器内执行相应 CUDA 调用拦截和限制。hami.io/vgpu-devices-to-allocate 与 hami.io/bind-phase 是分配进度协议，不是业务 Ready 标志，也不应由用户手工伪造。参见 HAMi Protocol。

同一节点不能让 HAMi 与 NVIDIA 官方 device plugin 同时争用 nvidia.com/gpu；GPU Operator 可负责其他软件组件，但要按目标版本关闭冲突的 allocation operand。HAMi-core 的软件拦截、MIG 的硬件分区以及 time-slicing 的共享策略也不能视为等价隔离保障，需验证实际调用路径、显存限制和尾延迟。HAMi FAQ 说明了插件共存及软件隔离边界。HAMi-DRA 改变的是 Claim/设备分配路径，仍可使用同一 HAMi-core 隔离层；切换分配 API 不会自动升级隔离强度。

D5 · 失败边界

失败矩阵是按职责归纳的排障边界，不承诺所有实现都可自动恢复。先判断故障停在 API 记账、节点准备、组件生命周期还是容器隔离，再对照 D2–D4 和具体 driver 的 conditions、events、日志与设备状态。

一句话分层

核心项目边界

node-feature-discovery

NFD 提供 worker/master、topology-updater 与 GC，发布硬件/系统能力、规则标签及资源拓扑。它帮助 scheduler 和 Operator 识别节点，不维护每个 Pod 的设备 allocation，也不替代 Device Plugin 或 DRA driver。

k8s-device-plugin

NVIDIA 官方 GPU device plugin 是传统路径的基线：通过 NVML/CUDA discovery 向 kubelet gRPC 注册 nvidia.com/gpu 等资源，并在 Allocate 阶段用 env、volume、CDI 等方式交接设备配置。它可提供配置支持的 MIG/time-slicing/MPS 资源暴露，但不负责 driver 生命周期、完整多租户治理或模型 serving。

gpu-operator

GPU Operator 是生产集群运维入口：传统 ClusterPolicy / NVIDIADriver 路径管理 driver、container toolkit、device plugin、DCGM、MIG manager、validator 等组件；当前 GPUCluster 提供另一条 DRA 管理路径，依赖独立 driver/runtime 准备。它解决“节点 GPU 软件栈怎样持续正确”，不决定单次 Pod 获得哪块设备。

hami

HAMi 是 GPU sharing / vGPU 方向的重要样本。它通过 webhook、scheduler extender、device plugin 和多厂商 device abstraction，把 GPU 显存、算力、切分和调度策略放到 K8s 资源模型旁边。它解决“多个 workload 如何共享 GPU”，但也带来调度、隔离、观测和兼容性的复杂度。

dra-driver-nvidia-gpu

NVIDIA DRA driver 把设备库存与节点准备接入 ResourceClaim / ResourceSlice 分配模型，GPU 与 ComputeDomain 路径具有各自生命周期。基础 DRA 已稳定，但动态设备、sharing、VFIO 等能力仍需按 Kubernetes 扩展和厂商 release 分别评估，不能无条件替代现有 device plugin 部署。

和 LLM serving 的关系

llm-inference 会把 GPU 资源层进一步拉进架构设计：

• Prefill/Decode 分离要求不同 GPU 池承担不同负载。
• KV cache offload 让显存、CPU 内存、NVMe 和网络都成为资源决策。
• LoRA / adapter serving 需要更细的内存与模型资产管理。
• GPU sharing 会影响 tail latency，不能只看平均利用率。
• DRA/CDI 会影响 serving operator 如何把“设备分配结果”交给 runtime。

所以 GPU stack 不应只作为运维背景，而应和 llm-d、aibrix、kserve、gpustack、kubeai、kueue、node-feature-discovery 等项目分层比较，区分 model serving、准入与节点发现。

选型提示

• 生产 NVIDIA GPU 集群基础栈：先看 gpu-operator + k8s-device-plugin。
• 多租户共享和 vGPU：看 hami，同时关注隔离和性能尾延迟。
• 下一代设备 API：看 kubernetes-dra + dra-driver-nvidia-gpu + cdi。
• LLM serving 平台：GPU 栈只是底座，还需要 llm-inference、inference-routing、model-serving-operator 和可观测能力。