NVIDIA GPU Operator：逐组件解析与全生命周期

GPU Operator 做的事可以一句话概括：把 GPU 节点的 Day-2 运维从“每台机器一遍的手工程序”变成“一个 YAML 声明的期望状态”。

Operator 究竟改变了什么

Operator 把期望的集群状态变成一个调谐循环（reconciliation loop）。平台描述策略，Operator 创建并守护组件，不必再在每台节点上手工安装驱动、设备插件、特性发现和遥测 DaemonSet。这提升了一致性，也让升级意图变得可见。

它也引入了一类新的故障：期望状态在某套版本矩阵里有效，在另一套里就是错的。调谐不能替代预检（preflight），升级仍要走金丝雀流程。

出现之前是什么样

在 GPU Operator（2020 年）之前，把一个 GPU 节点接入集群要在每台新节点上执行一套手工程序：安装匹配的内核驱动、安装并配置 Container Toolkit 与 containerd/CRI-O、手工部署设备插件 DaemonSet、手工配置 DCGM、MIG 场景还要逐卡分区；新增节点全部重来，升级驱动要排空、卸载、重装、重启。在 50 节点的集群里这是数周的苦役，而节点间驱动版本不一致会让分布式训练出现诡异的 NCCL 故障。

手工之痛的量化

没有 GPU Operator 的 GPU 集群团队，估计要把 60–80% 的 GPU 基础设施工程时间花在 Day-2 运维（驱动管理、节点维修、配置漂移），而不是工作负载优化上。

ClusterPolicy：唯一的配置点

ClusterPolicy 是 GPU Operator 安装的自定义资源定义（CRD），是配置整个 GPU 栈的唯一 YAML 文件：

# ClusterPolicy 骨架（简化）
apiVersion: nvidia.com/v1
kind: ClusterPolicy
metadata:
  name: cluster-policy
spec:
  driver:
    enabled: true
    version: '570.86.10'   # 锁定驱动版本
    rdma:
      enabled: false       # GPUDirect RDMA 时启用
  toolkit:
    enabled: true
    version: 'v1.17.3'
  devicePlugin:
    enabled: true
    version: 'v0.17.0'
    config:
      name: 'time-slicing-config'  # 可选共享配置
  dcgmExporter:
    enabled: true
    serviceMonitor:
      enabled: true        # Prometheus 抓取
  migManager:
    enabled: true
    config:
      name: 'default-mig-parted-config'
  gfd:
    enabled: true          # GPU Feature Discovery
  nfd:
    enabled: true          # Node Feature Discovery

八个组件的严格部署顺序

顺序	组件	为何是这个顺序
1	Node Feature Discovery（NFD）	必须先给节点打 OS、内核、PCI 设备信息标签；驱动选择依赖 OS 标签
2	NVIDIA 驱动容器	加载内核模块；必须先于其他一切能与 GPU 对话的组件
3	NVIDIA Container Toolkit	配置 containerd/CRI-O；必须先于 GPU Pod 存在
4	GPU Feature Discovery（GFD）	经 NVML 读取 GPU 属性（需驱动运行），打型号与 CUDA 能力标签
5	NVIDIA 设备插件	向 kubelet 注册 `nvidia.com/gpu`（需驱动 + 工具包）
6	DCGM + DCGM Exporter	经 NVML 采集指标，暴露 Prometheus 端点
7	MIG Manager	给 GPU 分区；在其余组件全部健康后应用
8	GPU Operator Validator	跑测试 CUDA 工作负载，端到端确认整栈可用

表 1: GPU Operator 组件部署顺序

理解这个顺序对排查启动故障必不可少：驱动容器没起来，后面全部白搭；Validator 是最后一块拼图。

组件要点

NVIDIA 驱动容器：特权 init 容器把 nvidia.ko 加载进主机内核，随后常驻防止模块卸载。节点可以带着纯净 OS 加入集群并自动获得正确驱动；支持开源内核模块（nvidia-open，Turing+ 默认，MIT 许可）。
NVIDIA Container Toolkit（托管）：自动配置各节点的 nvidia-container-runtime（原理见NVIDIA Container Toolkit），CDI 模式下还生成 CDI 规范。
NVIDIA 设备插件（托管）：暴露 nvidia.com/gpu 与 MIG 切片资源，通过 ConfigMap 配置时间切片副本与 MIG 策略，并支持 DRA 驱动模式。
DCGM + DCGM Exporter：暴露 50+ GPU 指标（9400 端口）、Xid 错误追踪与健康诊断（dcgmi diag），是可观测体系的数据源。
GFD：把 GPU 型号、显存、计算能力等打成节点标签，放置策略的 nodeSelector 用的正是这些标签，如 nvidia.com/gpu.product: NVIDIA-H100-80GB-HBM3。
NFD：探测硬件特性并打标签，同时驱动 NUMA 感知调度所需的 NodeResourceTopology 更新器（见NUMA 感知调度）。
MIG Manager：监视 MIG ConfigMap 变化，重配期间封锁/排空节点、重配每卡 MIG 实例、以新画像重启设备插件再解锁（与MIG章的运维代价分析对应）。
Validator：运行 CUDA 向量加测试，节点通过才标记验证完成，是生产负载落地前的最后一道闸。

Helm 安装与升级

# 安装（v26.3.0 为例）
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia && helm repo update

# 检查 NFD 是否已在运行（避免重复部署）
kubectl get nodes -o json | jq '.items[].metadata.labels | keys |
  any(startswith("feature.node.kubernetes.io"))'

helm install --wait --generate-name \
  -n gpu-operator --create-namespace \
  nvidia/gpu-operator \
  --version=v26.3.0

# 驱动已预装的场景（AKS/GKE/EKS 常见）
helm install --wait --generate-name \
  -n gpu-operator --create-namespace \
  nvidia/gpu-operator \
  --set driver.enabled=false

# 升级：CRD 先行（Helm 不会自动升级 CRD）
export RELEASE_TAG=v26.3.0
kubectl apply -f https://gitlab.com/nvidia/kubernetes/gpu-operator/-/raw/\
$RELEASE_TAG/deployments/gpu-operator/crds/nvidia.com_clusterpolicies_crd.yaml
helm upgrade gpu-operator-release nvidia/gpu-operator \
  -n gpu-operator --version $RELEASE_TAG --disable-openapi-validation

金丝雀升级循环与最小验证阶梯

冻结当前节点镜像与兼容性矩阵。
升级一个空的或可丢弃的 GPU 节点。
验证驱动、运行时、插件或 DRA、健康、遥测与拓扑。
运行单 GPU 冒烟测试与一个代表性应用。
若该节点类型承载此类负载，运行多 GPU 或推理扩展测试。
对比日志、指标、启动时间、吞吐与错误率。
向前推进，或排空回退；之后才扩展节点池。

# 最小验证阶梯
kubectl get nodes -l accelerator.example.com/enabled=true
kubectl get pods -n gpu-operator -o wide
kubectl get events -A --sort-by=.lastTimestamp | tail -80
kubectl run gpu-check --rm -it --restart=Never \
  --image=nvidia/cuda:12.8.1-base-ubuntu24.04 \
  --limits='nvidia.com/gpu=1' -- nvidia-smi

总结

GPU Operator 把软件栈各层与设备插件的部署收进一个控制循环，但它自动化的是“安装”，不是“决策”：版本矩阵、金丝雀与回滚仍是平台团队的责任（见安全、可靠性与生命周期）。与 Volcano/Kueue 的关系是互补而非替代：Operator 管“节点就绪”，调度器管“作业就绪”。

参考资料

NVIDIA GPU Operator 官方文档：About the NVIDIA GPU Operator。

创建于 2026/08/30 更新于 2026/08/30 1968 字阅读约 4 分钟