状态：草稿 (2026-10-07)。 Pod 名称、类型、初始化容器顺序、节点标签、安装选项组合均为在实际运行环境中通过只读方式确认的值。Operator 以容器方式加载驱动的方案在该环境中未被使用，故未能直接测试（未实测），是通过官方文档的描述确认的。 编写规则：实测数据为基础，未能测量的内容标注为「未实测」。
目录
- 1. 安装后启动的 Pod
- 2. Pod 相互等待：验证链
- 3. 宿主机上必须没有 NVIDIA 驱动吗
- 4. Pod 获取 GPU 的完整流程
- 5. 直接核对的只读命令
- 6. 常见误解
- 确认的版本与日期、未确认的内容
- 参考资料
初次使用 GPU Operator 时， gpu-operator 命名空间中会启动十几个 Pod，仅从名称很难分辨哪个是什么。本文将回答以下两个问题。
- 每个 Pod 的工作是什么、运行在哪个节点上、缺失时会出现什么症状。
- 即使宿主机上未安装 NVIDIA 驱动，仅凭 GPU Operator 也能使用 GPU 吗。
简短的回答。 Pod 大致分为控制器 (Deployment)、节点标签选择器 (NFD)，以及每个 GPU 节点上运行一个的 DaemonSet 集合（驱动、工具包、设备插件、GFD、DCGM Exporter、验证器）。宿主机上可以没有驱动，因为 Operator 默认会将驱动作为容器启动。相反，如果宿主机上已经安装了驱动，可以采用关闭 Operator 驱动的配置(driver.enabled=false)，这在实际中很常见。这两种方式的区别在于「由谁来管理驱动的生命周期」。
1. 安装后启动的 Pod
这是在 GPU Operator (v26.3.3) 实际运行的环境中读取 gpu-operator 命名空间的结果。数字（节点数）因环境而异，因此仅整理类型和角色。
| Pod（资源名称） | 类型 | 运行位置 | 工作内容 | 缺失或失败时的影响 |
|---|---|---|---|---|
gpu-operator |
Deployment | 集群中一个 | 控制器。读取 ClusterPolicy 并创建下方的 DaemonSet，同时管理节点标签(nvidia.com/gpu.deploy.*) |
无法部署任何新内容，配置变更无法生效 |
gpu-operator-node-feature-discovery-master, -gc |
Deployment | 集群中每个各一个 | NFD 的核心组件。为 worker 发送的硬件信息附加标签 (master)，并清理消失节点的过期对象 (gc) | 节点标签无法更新 |
gpu-operator-node-feature-discovery-worker |
DaemonSet | 所有节点 | 读取并报告节点的 PCI 设备、内核等。如果存在 NVIDIA 设备，则会生成 feature.node.kubernetes.io/pci-10de.present 标签，Operator 据此将其判断为 GPU 节点 |
无法识别为 GPU 节点，导致下方 DaemonSet 的所需副本数变为 0 |
nvidia-driver-daemonset |
DaemonSet | GPU 节点 | 以容器方式安装 NVIDIA 驱动（内核模块）。如果宿主机上有驱动，可将其关闭以避免创建（第 3 节） | nvidia-smi 会失败，其他 Pod 会在初始化阶段等待 |
nvidia-container-toolkit-daemonset |
DaemonSet | GPU 节点 | 在容器运行时 (containerd) 中注册 nvidia 运行时处理程序，并安装将 GPU 设备和库注入容器的工具 |
no runtime for "nvidia" is configured |
nvidia-device-plugin-daemonset |
DaemonSet | GPU 节点 | 注册到 kubelet 以通告 nvidia.com/gpu 数量，当 Pod 请求 GPU 时通过 Allocate 分配设备。同时监控设备健康状况 (XID) |
节点的 nvidia.com/gpu 丢失或减少 |
gpu-feature-discovery |
DaemonSet | GPU 节点 | 附加 GPU 专用标签（GPU 型号、数量、内存、驱动版本等，如nvidia.com/gpu.product, nvidia.com/gpu.count 等） |
按型号调度的标签消失（对 GPU 本身的通告无影响） |
nvidia-dcgm-exporter |
DaemonSet | GPU 节点 | 以 Prometheus 格式暴露 GPU 利用率、内存、温度、功耗和错误指标 | 仅缺少监控。若无法连接到独立的 DCGM，则会进入 CrashLoopBackOff |
nvidia-operator-validator |
DaemonSet | GPU 节点 | 按顺序验证安装是否正确（第 2 节） | 指出在验证阶段停止的 Pod 是哪个组件的问题 |
nvidia-cuda-validator |
短生命周期 Pod | 验证时生成，结束后完成 | 实际运行一次 CUDA 示例 | 验证失败 |
nvidia-mig-manager |
DaemonSet | 启用了 MIG 的节点 | 应用 MIG 配置文件 | 在无法使用 MIG 的 GPU 上无意义（本环境已关闭） |
nvidia-device-plugin-mps-control-daemon |
DaemonSet | 启用了 MPS 的节点 | MPS 控制守护进程。本环境中所需副本数为 0，故无此 Pod | 不使用该功能则无影响 |
在 NVSwitch 系统（如 HGX 等）中，需要单独配置用于构建 GPU 间 Fabric 的 Fabric Manager 。Operator 的驱动容器在检测到 NVSwitch 时会自动安装它，若使用宿主机驱动则需手动直接安装（根据官方文档描述，本环境无 NVSwitch 故未能测试，未实测）。
2. Pod 相互等待：验证链
虽然 GPU 节点上的 DaemonSet 是同时启动的，但它们之间存在依赖顺序。这是通过实际 Pod 的初始化容器名称确认的顺序。
| Pod | 初始化容器（实际名称） | 含义 |
|---|---|---|
nvidia-operator-validator |
driver-validation → toolkit-validation → cuda-validation → plugin-validation |
依次检查驱动是否加载、工具箱是否安装、CUDA 示例是否运行、插件是否宣告设备，全部通过后本容器才会启动 |
nvidia-container-toolkit-daemonset |
driver-validation |
工具箱会等待驱动准备就绪后再进行安装 |
nvidia-device-plugin-daemonset, gpu-feature-discovery |
toolkit-validation(和 config-manager-init) |
插件和 GFD 必须在工具箱验证完成后才能启动 |
nvidia-dcgm-exporter |
(无，仅此一个容器) | 无需单独等待即可启动 |
因此，如果某个步骤受阻，后续阶段的 Pod 将停留在 Init:0/1 状态，问题的根源在于最前方受阻的步骤。诊断应按照 驱动 → 工具箱 → 插件 的顺序从前到后进行。
Operator 通过节点标签决定在哪个节点上运行哪个 DaemonSet。检查后会发现，每个 GPU 节点上都贴有 nvidia.com/gpu.deploy.driver, .container-toolkit, .device-plugin, .gpu-feature-discovery, .dcgm, .dcgm-exporter, .operator-validator, .node-status-exporter 标签，且值为 "true" ，各 DaemonSet 通过 nodeSelector 读取该标签。如果想在特定节点上关闭某个组件，只需将该节点的相应标签更改为 false 即可。
3. 主机上是否可以没有 NVIDIA 驱动
可以。 官方文档称 driver.enabled 的默认值为 true, toolkit.enabled 的默认值为 true ，并且 Operator 会将驱动作为容器(nvidia-driver-daemonset)进行安装。因此，只要插有 GPU 的节点上拥有操作系统和容器运行时，Operator 就会负责启动其余部分。
有三种配置。
| 配置 | Helm 옵션 | 驱动程序 | 工具包 | 当遇到这种情况时 |
|---|---|---|---|---|
| 全部由 Operator 管理 | 默认值 | Operator 的驱动程序容器 | Operator | 当节点操作系统完全一致，且希望由 Operator 统一管理升级时 |
| 仅主机驱动程序 | --set driver.enabled=false |
预先安装在主机上 | Operator | 当存在混合操作系统或通过单独的流程（镜像、包）管理驱动程序时。 本文的验证环境即为此配置 |
| 主机上两者皆有 | --set driver.enabled=false --set toolkit.enabled=false |
主机 | 主机 | 像 DGX 这样的预配置系统。文档指出在这种情况下，默认运行时应该 nvidia 设置为 |
已确认环境的 ClusterPolicy 是 driver.enabled=false, toolkit.enabled=true，设备插件、GFD 和 DCGM Exporter 已启用，MIG Manager 已禁用，其结果是 nvidia-driver-daemonset 根本没有被创建。尽管如此，验证器全部通过了，并且每个 GPU 节点上的插件 nvidia.com/gpu 进行了广告。即 “宿主机驱动 + Operator 的 Toolkit、插件、指标”的组合确实能够实际工作。 此时 Toolkit Pod 会挂载宿主机根目录(/)和驱动安装路径(/run/nvidia/driver)，并在启动前通过 driver-validation 检查宿主机驱动是否可用（第 2 节）。
当宿主机已经存在驱动但没有关闭 driver.enabled 时，官方文档中有关于自动检测的说明。据说当驱动 Pod 的初始化容器检测到预安装的驱动时，会对节点打上标签以终止驱动 Pod 并且不再重新调度（这是阅读文档所得，未在该环境中实际测试，未经实测）。即便如此，为了明确意图，最好还是显式配置。
驱动容器方式的代价。
- 每个节点都需要与操作系统版本和内核相匹配的驱动镜像。内核更新后必须重新匹配驱动，而预编译镜像的标签是
<브랜치>-<커널>-<OS>格式，因此必须存在该组合。 - 由于驱动是内核模块，在替换之前必须停止所有使用 GPU 的 Pod。Operator 会通过 cordon、等待、删除 GPU Pod 以及可选的 drain 以状态机的方式对其进行管理，因此在升级期间无法使用该节点的 GPU。
- 如果启用了自动内核升级(
unattended-upgrades)，内核变更后驱动可能会不匹配，因此官方文档建议将其关闭。
宿主机驱动方式的代价。 Operator 不管理宿主机驱动的生命周期（升级、替换）。相反，即使节点操作系统各不相同，也可以通过团队现有的方式（镜像、包管理）来控制驱动替换流程。
4. Pod 获取 GPU 的过程
这是安装完成后的流程。
- 设备插件注册到 kubelet并传递设备列表。
- kubelet 更新节点状态的
capacity和allocatable字段（nvidia.com/gpu: N). - 调度器只看这些数字，不看设备本身（
NodeResourcesFit）。GPU 仅用于limits（如果使用requests，则它们必须具有相同的值）且为整数。 - kubelet 调用
Allocate，并作为响应接收到设备节点、环境变量、挂载点以及 CDI 名称。 - 容器运行时注入设备。从 Operator 25.10.0 版本开始，默认使用 CDI（Container Device Interface），常规工作负载不再需要
runtimeClassName。
如果与插件的连接断开，kubelet 会将设备标记为 unhealthy，将 allocatable 降为 0，并且在 5 分钟的宽限期过后清除资源名称（摘自 kubelet 源码说明）。因此，即使“Insufficient nvidia.com/gpu”事件相同，其原因也可能是插件、Toolkit、驱动或调度约束中的任意一个。
5. 直接确认的只读命令
# 오퍼레이터가 올린 파드와 노드별 분포
kubectl -n gpu-operator get deploy,ds
kubectl -n gpu-operator get po -o wide
# 오퍼레이터가 어떤 구성요소를 켰는가(ClusterPolicy)
kubectl get clusterpolicy -o jsonpath='{.items[0].spec.driver.enabled} {.items[0].spec.toolkit.enabled}{"\n"}'
# 노드별 GPU 광고량과 GPU 라벨
kubectl get nodes -o custom-columns=N:.metadata.name,CAP:.status.capacity.nvidia\.com/gpu,ALLOC:.status.allocatable.nvidia\.com/gpu
kubectl get nodes -L nvidia.com/gpu.present,nvidia.com/gpu.product
# 어떤 노드에 어떤 구성요소를 띄우도록 라벨이 붙었는가
kubectl get node <노드> -o json | grep -o 'nvidia.com/gpu.deploy[^,]*'
# 검증기가 막힌 곳(초기화 컨테이너 이름이 막힌 단계)
kubectl -n gpu-operator describe po -l app=nvidia-operator-validator | grep -A2 -i "init containers"
6. 常见误解
- “GPU Operator 就是一个驱动安装程序。” 驱动只是其中的一个组件。即使在使用宿主机驱动的环境中，由于 Toolkit 安装、插件注册、标签管理、指标和验证等原因，Operator 仍然非常有用。
- “有了宿主机驱动就不需要 Operator 了。” 仅靠驱动无法让 Kubernetes 将 GPU 视为资源。必须配置设备插件和容器运行时才能生成
nvidia.com/gpu。Operator 会自动将这两者进行适配。 - “部署 Operator 后，containerd 的配置就是安全的。” Toolkit 会修改宿主机的 containerd 配置文件(
/etc/containerd)。如果与其它配置文件冲突，CRI 配置可能会被整体替换（containerd 1.7 的配置合并会把 plugin 节整体替换，详见源码）。请参考第 03 篇第 5 节。 - “当工具包向 containerd 发送 SIGHUP 时，仅重新读取配置。” 在一次性虚拟机中的 containerd 2.2.1 上测试发送 SIGHUP 后，进程退出了，systemd 在 5 秒后将其重新拉起（
Restart=always）。这就是为什么要逐个节点应用、而不是一次性替换所有节点的原因（参考第 03 篇）。 - 「
nvidia.com/gpu.present即可视为安装完成。” 这个标签意味着 NFD 和 Operator 已经检测到了 GPU 硬件，但并不代表驱动和插件正在运行。必须检查节点的allocatable以及验证器状态。
确认过的版本与日期、未确认的事项
于 2026-10-07 读取的环境为 GPU Operator v26.3.3、Container Toolkit v1.19.1、Device Plugin v0.19.3、NFD v0.18.3、DCGM Exporter 4.5.3-4.8.2（distroless 镜像）。官方文档通过打开安装指南和概览页面进行了确认。
- Operator 的驱动容器化方案未直接进行测试（未实测）。 因为确认的环境使用的是宿主机驱动。该方案的运行机制和开销依据的是官方文档的描述。
- 当存在宿主机驱动时的自动检测（关闭驱动 Pod）仅阅读了文档，未进行测试。
- NVSwitch 系统的 Fabric Manager 运行机制、MIG Manager 的实际应用以及 MPS 在此环境中未使用，故未确认。
- Pod 列表是某一时刻的快照，组件会根据配置增加或减少（此环境中没有沙箱工作负载适用的 KubeVirt 设备插件、vGPU 管理器等）。
参考资料
- NVIDIA GPU Operator 概览: https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/overview.html
- NVIDIA GPU Operator 入门（预安装驱动与 Helm 选项）: https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/getting-started.html
- 本系列第 3 篇（GPU Operator 栈解析与排错）、第 17 篇（DCGM Exporter 指标）、第 22 篇（知识图谱）