Nvidia GPU Operator 面试题
30 道题- 分类
- Kubernetes
- 子分类
- gpu
- 题目数
- 30 道
1 Nvidia GPU Operator 的核心架构是什么?
答案:
Nvidia GPU Operator 是 Kubernetes 上管理 GPU 资源的自动化方案,通过 Operator 模式自动部署和管理 GPU 驱动、容器运行时和设备插件。
架构组成:
graph TD
A[Nvidia GPU Operator] --> B[Node Feature Discovery<br/>NFD]
A --> C[GPU Driver Installer<br/>DaemonSet]
A --> D[GPU Feature Discovery<br/>GFD]
A --> E[DCGM Exporter]
A --> F[Container Runtime<br/>nvidia-container-toolkit]
A --> G[Device Plugin]
A --> H[MIG Manager]
A --> I[GPU Time-Slicing]
B --> B1[检测 GPU 硬件特征]
B --> B2[节点标签注入]
C --> C1[自动安装 GPU 驱动]
C --> C2[驱动版本管理]
D --> D1[GPU 型号和显存检测]
D --> D2[节点 GPU 标签]
E --> E1[GPU 指标暴露]
E --> E2[遥测数据采集]
F --> F1[Docker/containerd/cri-o<br/>运行时配置]
F --> F2[GPU 设备挂载]
G --> G1[nvidia.com/gpu<br/>资源注册]
G --> G2[GPU 分配和调度]
H --> H1[MIG 配置管理]
H --> H2[GPU 分区]
I --> I1[GPU 时间片调度]
I --> I2[共享 GPU 资源]
2 GPU Operator 如何自动安装 GPU 驱动?
答案:
GPU Operator 通过 Driver DaemonSet 实现 GPU 驱动的自动化安装和更新。
驱动安装流程:
1. NFD 检测 GPU 硬件
2. Driver DaemonSet 启动
3. 下载 GPU 驱动包
4. 编译内核模块(dkms)
5. 安装 nvidia.ko
6. 创建 /dev/nvidia* 设备
7. 验证驱动加载
8. 节点 Ready
Driver 配置:
apiVersion: v1
kind: ConfigMap
metadata:
name: nvidia-driver-config
data:
driverVersion: "535.154.05"
image: nvcr.io/nvidia/driver:535.154.05-ubuntu22.04
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nvidia-driver-daemonset
spec:
selector:
matchLabels:
app: nvidia-driver
template:
spec:
containers:
- name: nvidia-driver
image: nvcr.io/nvidia/driver:535.154.05-ubuntu22.04
securityContext:
privileged: true
volumeMounts:
- name: host-root
mountPath: /host
env:
- name: ROOT_MOUNT_DIR
value: /host
volumes:
- name: host-root
hostPath:
path: /
3 Nvidia Device Plugin 的工作原理是什么?
答案:
Nvidia Device Plugin 是实现 GPU 资源注册和调度的关键组件,负责将 GPU 设备上报给 Kubelet。
工作流程:
graph TD
A[GPU Device Plugin] -->|1. ListAndWatch 注册 GPU 资源| B[向 Kubelet 注册 nvidia.com/gpu]
B --> B1[上报 GPU 数量]
B --> B2[设备 ID 和健康状态]
A -->|2. Allocate 分配 GPU| C[接收 Pod 的 GPU 请求]
C --> C1[返回环境变量]
C --> C2[返回设备卷挂载]
A -->|3. 健康检测| D[定期检查 GPU 状态]
D --> D1[检测 GPU 故障]
D --> D2[异常 GPU 从可用列表移除]
Device Plugin 配置:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nvidia-device-plugin-daemonset
spec:
selector:
matchLabels:
name: nvidia-device-plugin-ds
template:
spec:
containers:
- name: nvidia-device-plugin-ctr
image: nvcr.io/nvidia/k8s-device-plugin:v0.14.0
env:
- name: NVIDIA_VISIBLE_DEVICES
value: all
volumeMounts:
- name: device-plugin
mountPath: /var/lib/kubelet/device-plugins
volumes:
- name: device-plugin
hostPath:
path: /var/lib/kubelet/device-plugins
4 GPU Operator 支持的 GPU 共享方案有哪些?
答案:
GPU Operator 支持 MIG、Time-Slicing 和 GPU 共享三种资源分配模式。
方案对比:
| 方案 | 隔离级别 | GPU 利用率 | 适用场景 |
|---|---|---|---|
| MIG | 硬件隔离(A100/H100) | 高 | AI 训练、推理 |
| Time-Slicing | 时间片共享 | 中 | 推理服务 |
| GPU 共享(vGPU) | 进程级隔离 | 中 | 开发测试 |
MIG 配置:
apiVersion: v1
kind: ConfigMap
metadata:
name: mig-config
data:
config.yaml: |
version: v1
flags:
migEnabled: true
migConfigs:
all:
- devices: [0,1,2,3,4,5,6,7]
migEnabled: true
migDeviceSpecs:
- devices:
- parentDevice: 0
migProfile: 1g.10gb
- parentDevice: 1
migProfile: 3g.40gb
Time-Slicing 配置:
apiVersion: v1
kind: ConfigMap
metadata:
name: time-slicing-config
data:
config.yaml: |
version: v1
sharing:
timeSlicing:
resources:
- name: nvidia.com/gpu
replicas: 4
failRequestsGreaterThanOne: false
5 GPU Operator 的 MIG(Multi-Instance GPU)管理是什么?
答案:
MIG 技术将一块物理 GPU 切割为多个独立实例,每个实例拥有独立的显存和计算资源。
MIG Profiles:
| MIG Profile | 计算单元 | 显存 | 适用场景 |
|---|---|---|---|
| 1g.5gb | 1/7 GPU | 5GB | 小型推理 |
| 1g.10gb | 1/7 GPU | 10GB | 中型推理 |
| 2g.20gb | 2/7 GPU | 20GB | 训练推理 |
| 3g.40gb | 3/7 GPU | 40GB | 训练 |
| 4g.40gb | 4/7 GPU | 40GB | 训练 |
| 7g.80gb | 全 GPU | 80GB | 大型训练 |
MIG 管理器配置:
apiVersion: v1
kind: ConfigMap
metadata:
name: mig-manager-config
data:
config.yaml: |
version: v1
flags:
migEnabled: true
migConfigs:
node-0:
- devices: ["GPU-xxx"]
migEnabled: true
migDeviceSpecs:
- devices:
- parentDevice: "GPU-xxx"
migProfile: "3g.40gb"
Pod 使用 MIG:
apiVersion: v1
kind: Pod
spec:
containers:
- name: cuda-container
image: nvidia/cuda:12.0-base
resources:
limits:
nvidia.com/gpu: 1
nvidia.com/mig-profile: "1g.10gb"
6 DCGM Exporter 的 GPU 监控指标有哪些?
答案:
DCGM(Data Center GPU Manager)Exporter 暴露全面的 GPU 遥测指标,集成 Prometheus 生态。
核心指标:
| 指标名 | 类型 | 说明 |
|---|---|---|
| DCGM_FI_DEV_GPU_UTIL | Gauge | GPU 利用率 (%) |
| DCGM_FI_DEV_MEM_COPY_UTIL | Gauge | 显存带宽利用率 (%) |
| DCGM_FI_DEV_ENC_UTIL | Gauge | 编码器利用率 (%) |
| DCGM_FI_DEV_DEC_UTIL | Gauge | 解码器利用率 (%) |
| DCGM_FI_DEV_XID_ERRORS | Counter | XID 错误计数 |
| DCGM_FI_DEV_POWER_USAGE | Gauge | 功耗 (mW) |
| DCGM_FI_DEV_FB_FREE | Gauge | 可用显存 (MB) |
| DCGM_FI_DEV_FB_USED | Gauge | 已用显存 (MB) |
| DCGM_FI_DEV_TEMPERATURE | Gauge | GPU 温度 (C) |
| DCGM_FI_DEV_PCIE_REPLAY_COUNTER | Counter | PCIe 重放计数 |
| DCGM_FI_DEV_RETIRED_PENDING | Gauge | 待退休内存页 |
Prometheus 告警规则:
groups:
- name: gpu-alerts
rules:
- alert: GPUHighTemperature
expr: DCGM_FI_DEV_TEMPERATURE{gpu=~".*"} > 85
for: 5m
labels:
severity: critical
- alert: GPUXIDError
expr: rate(DCGM_FI_DEV_XID_ERRORS[5m]) > 0
for: 1m
labels:
severity: critical
- alert: GPUMemoryLow
expr: (DCGM_FI_DEV_FB_FREE / (DCGM_FI_DEV_FB_USED + DCGM_FI_DEV_FB_FREE)) * 100 < 10
for: 5m
labels:
severity: warning
7 GPU Operator 的节点标签和调度机制是什么?
答案:
GPU Operator 通过 GFD 和 NFD 为 GPU 节点自动添加标签,支持精细化调度。
自动注入标签:
| 标签 | 来源 | 说明 |
|---|---|---|
| nvidia.com/gpu.present | NFD | GPU 是否存在 |
| nvidia.com/gpu.count | GFD | GPU 数量 |
| nvidia.com/gpu.memory | GFD | GPU 显存 |
| nvidia.com/gpu.product | GFD | GPU 型号 |
| nvidia.com/mig.config | GFD | MIG 配置状态 |
| nvidia.com/gpu.driver.version | Driver | 驱动版本 |
| feature.node.kubernetes.io/pci-10de.present | NFD | NVIDIA PCI 设备 |
调度策略:
# 节点选择(指定 GPU 型号)
apiVersion: v1
kind: Pod
spec:
nodeSelector:
nvidia.com/gpu.product: NVIDIA-A100-SXM4-80GB
# 拓扑约束
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: nvidia.com/gpu.count
operator: Gt
values:
- "2"
GPU 资源声明:
apiVersion: v1
kind: Pod
spec:
containers:
- name: gpu-container
resources:
limits:
nvidia.com/gpu: 2 # 申请 2 块 GPU
8 GPU Operator 的多 GPU 通信(NVLink/NVSwitch)管理是什么?
答案:
GPU Operator 支持 NVLink 和 NVSwitch 拓扑感知调度,优化多 GPU 通信性能。
NVLink 拓扑:
NVLink 连接拓扑:
GPU-0 ── NVLink ── GPU-1
│ │
NVLink NVLink
│ │
GPU-2 ── NVLink ── GPU-3
NVSwitch(DGX A100/H100):
所有 GPU 通过 NVSwitch 全互联
任意 GPU 间 P2P 带宽: 600GB/s (A100)
拓扑感知调度:
apiVersion: v1
kind: ConfigMap
metadata:
name: topology-config
data:
topology.yaml: |
version: v1
policies:
- name: best-effort
# 尽量分配同一 NVSwitch 域的 GPU
preferences:
- nvlink
# 至少分配同一节点
requirements:
- numa
Pod 拓扑请求:
apiVersion: v1
kind: Pod
spec:
containers:
- name: training
resources:
limits:
nvidia.com/gpu: 8
nvidia.com/nvlink: 4
9 GPU Operator 的故障检测和自愈机制是什么?
答案:
GPU Operator 通过设备插件健康检测和 XID 错误处理实现 GPU 故障管理。
XID 错误处理:
XID 错误类型:
XID 13: GPU 停止运行(致命)
XID 31: 显存页面错误
XID 43: GPU 挂起
XID 48: 双 ECC 错误
XID 64: GPU 掉线
XID 79: GPU 温度过高
处理策略:
非致命错误(XID 31):
标记异常 GPU
通知上层应用
致命错误(XID 13/43/48):
从可用设备列表移除
驱逐受影响 Pod
触发节点维护
健康检测:
# 设备插件健康检测配置
apiVersion: v1
kind: ConfigMap
metadata:
name: device-plugin-config
data:
config.yaml: |
version: v1
flags:
migStrategy: "mixed"
failOnInitError: true
deviceListStrategy: envvar
nvidiaDriverRoot: /
health:
healthCheckInterval: 10s
unhealthyDeviceThreshold: 3
Pod 驱逐策略:
# GPU 故障时的 Pod 驱逐
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
containers:
- name: gpu-workload
resources:
limits:
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
operator: Exists
effect: NoExecute
10 GPU Operator 的升级策略是什么?
答案:
GPU Operator 支持滚动升级,驱动升级和 Operator 升级分开执行。
驱动升级流程:
1. 排空 GPU 节点
kubectl drain <node> --ignore-daemonsets
2. 更新 Driver 版本
kubectl set image daemonset/nvidia-driver-daemonset \
nvidia-driver=nvcr.io/nvidia/driver:545.23.08-ubuntu22.04
3. 验证驱动加载
kubectl logs nvidia-driver-xxxxx
kubectl exec nvidia-driver-xxxxx -- nvidia-smi
4. 恢复调度
kubectl uncordon <node>
Operator 升级流程:
# Helm 升级
helm upgrade gpu-operator nvidia/gpu-operator \
--namespace gpu-operator \
--version v23.9.0 \
--set driver.version=545.23.08
# 验证升级
kubectl get pods -n gpu-operator
kubectl describe pod nvidia-device-plugin-xxxxx
升级注意事项:
1. 驱动升级需要节点排空
2. 大版本升级需逐步执行
3. 备份配置和 CRD
4. 监控 GPU 工作负载状态
5. 灰度升级(分批节点)
11 GPU Operator 的 vGPU 和 GPU 分区有什么区别?
答案:
vGPU(虚拟 GPU)和 GPU 分区(MIG)是实现 GPU 共享的两种不同技术。
对比分析:
| 维度 | MIG (A100/H100) | vGPU (Tesla/Quadro) |
|---|---|---|
| 隔离级别 | 硬件级隔离 | 软件级隔离 |
| 显存隔离 | 物理隔离 | 无(共享显存) |
| 性能保障 | 确定性 | 尽力而为 |
| License 要求 | 无 | 需要 vGPU License |
| 适用 GPU | A100, H100 | T4, V100, A10 |
| 热迁移 | 不支持 | 支持 |
| GPU 利用率 | 高 | 中 |
MIG 使用场景:
MIG:
- 多租户 GPU 资源隔离
- 混合负载(训练 + 推理)
- 需要确定性性能
vGPU:
- VDI 桌面虚拟化
- 开发测试环境
- 需要 GPU 热迁移
12 GPU Operator 与普通 GPU 节点部署的对比是什么?
答案:
GPU Operator 自动化了 GPU 节点的管理流程,相比手动部署减少了运维复杂度。
对比分析:
| 维度 | 手动部署 | GPU Operator |
|---|---|---|
| 驱动安装 | 手动编译/安装 | 自动 DaemonSet |
| 驱动升级 | 全节点手动操作 | 滚动更新 |
| 设备插件 | 手动配置 | Operator 自动管理 |
| MIG 管理 | 手动配置 | MIG Manager CRD |
| 监控集成 | 手动部署 DCGM | 内置 Exporter |
| 节点标识 | 手动打标签 | NFD + GFD 自动 |
| GPU 共享 | 手动配置 | Time-Slicing/MIG CRD |
| 版本管理 | 手动记录 | Operator 统一管理 |
13 GPU Operator 的资源配额和限制如何配置?
答案:
GPU Operator 通过 K8s ResourceQuota 和 LimitRange 管理 GPU 资源使用。
GPU ResourceQuota:
apiVersion: v1
kind: ResourceQuota
metadata:
name: gpu-quota
namespace: ai-training
spec:
hard:
requests.nvidia.com/gpu: 8
limits.nvidia.com/gpu: 8
apiVersion: v1
kind: LimitRange
metadata:
name: gpu-limits
spec:
limits:
- max:
nvidia.com/gpu: 4
min:
nvidia.com/gpu: 1
type: Container
Namespace 配额管理:
# 多团队 GPU 配额
apiVersion: v1
kind: ResourceQuota
metadata:
name: team-a-gpu
namespace: team-a
spec:
hard:
nvidia.com/gpu: 16
apiVersion: v1
kind: ResourceQuota
metadata:
name: team-b-gpu
namespace: team-b
spec:
hard:
nvidia.com/gpu: 8
14 GPU Operator 的多集群 GPU 资源管理方案是什么?
答案:
GPU Operator 配合集群联邦或全局调度器实现多集群 GPU 资源统一管理。
多集群架构:
全局调度层
│
├── 集群 A (GPU: A100×32)
│ └── GPU Operator
│
├── 集群 B (GPU: A100×64)
│ └── GPU Operator
│
└── 集群 C (GPU: H100×128)
└── GPU Operator
全局资源视图:
- Total GPU: 224
- Total VRAM: 17.5TB
训练作业多集群调度:
# Volcano 跨集群调度
apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
name: multi-cluster-gpu
spec:
weight: 1
capability:
cpu: "1000"
memory: "8TB"
nvidia.com/gpu: "224"
apiVersion: batch.volcano.sh/v1alpha1
kind: Job
spec:
schedulerName: volcano
queue: multi-cluster-gpu
tasks:
- replicas: 32
template:
spec:
containers:
- name: training
resources:
limits:
nvidia.com/gpu: 8
15 GPU Operator 的安全配置和合规要求是什么?
答案:
GPU Operator 支持 Pod Security Admission、SELinux 和 AppArmor 等安全机制。
Pod Security 配置:
apiVersion: v1
kind: Namespace
metadata:
name: gpu-workloads
labels:
pod-security.kubernetes.io/enforce: privileged
pod-security.kubernetes.io/warn: baseline
SELinux 配置:
# SELinux 上下文配置
apiVersion: v1
kind: Pod
spec:
securityContext:
seLinuxOptions:
level: "s0:c1,c2"
type: "container_t"
containers:
- name: gpu-container
securityContext:
privileged: true
capabilities:
add:
- SYS_ADMIN
- SYS_PTRACE
容器运行时安全:
# NVIDIA Container Toolkit 安全配置
/etc/nvidia-container-runtime/config.toml:
# 禁用不需要的特性
disable-require: false
# 启用 NVIDIA 驱动限制
nvidia-container-cli:
# 显存限制
environment: ["NVIDIA_VISIBLE_DEVICES=all"]
# 限制计算能力
capabilities:
- compute
- utility
16 GPU Operator 的 Helm 安装与核心配置参数
答案:
GPU Operator 通过 Helm Chart 部署,ClusterPolicy CR 为核心配置入口。
Helm 安装命令:
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update
helm install gpu-operator nvidia/gpu-operator \
--namespace gpu-operator \
--create-namespace \
--set driver.version=535.154.05 \
--set operator.defaultRuntime=crio \
--set toolkit.version=1.14.0 \
--set devicePlugin.version=v0.14.0 \
--set migManager.enabled=true
核心 Helm 配置参数:
| 参数 | 默认值 | 说明 |
|---|---|---|
| driver.enabled | true | 启用驱动 DaemonSet |
| driver.version | 最新稳定版 | 指定驱动版本 |
| toolkit.enabled | true | 启用 Container Toolkit |
| devicePlugin.enabled | true | 启用 Device Plugin |
| devicePlugin.config.name | "" | Device Plugin 配置 ConfigMap |
| migManager.enabled | false | 启用 MIG Manager |
| gfd.enabled | true | 启用 GPU Feature Discovery |
| dcgm.enabled | true | 启用 DCGM 监控 |
| operator.defaultRuntime | containerd | 容器运行时类型 |
| node-feature-discovery.enabled | true | 启用 NFD |
ClusterPolicy CR 示例:
apiVersion: nvidia.com/v1
kind: ClusterPolicy
metadata:
name: cluster-policy
spec:
operator:
defaultRuntime: containerd
deployGFD: true
driver:
enabled: true
version: "535.154.05"
toolkit:
enabled: true
devicePlugin:
enabled: true
config:
name: device-plugin-config
migManager:
enabled: true
config:
name: mig-manager-config
gfd:
enabled: true
17 nvidia-container-toolkit 的工作原理是什么?
答案:
nvidia-container-toolkit 通过 OCI prestart hook 和容器运行时配置,实现 GPU 设备向容器的透传。
工作流程:
1. 容器创建请求
│
2. OCI runtime spec 生成
│
3. nvidia-container-runtime-hook 拦截
│
4. 检测 NVIDIA_VISIBLE_DEVICES 环境变量
│
5. 注入 GPU 设备文件(/dev/nvidia*)
│
6. 注入 GPU 库依赖(libcuda.so、libnvidia-ml.so)
│
7. 挂载 nvidia-container-toolkit 驱动目录
│
8. 容器启动,GPU 可见
containerd 运行时配置:
# /etc/containerd/config.toml
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia]
runtime_type = "io.containerd.runc.v2"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia.options]
BinaryName = "/usr/bin/nvidia-container-runtime"
环境变量控制:
| 环境变量 | 说明 |
|---|---|
| NVIDIA_VISIBLE_DEVICES | 可见 GPU 设备列表 |
| NVIDIA_DRIVER_CAPABILITIES | 驱动能力:compute, graphics, utility, video, display |
| NVIDIA_REQUIRE_CUDA | 要求 CUDA 版本 |
| NVIDIA_DISABLE_REQUIRE | 跳过 CUDA 版本检查 |
18 GPU Operator 的 Validator 与预检机制
答案:
GPU Operator 通过 Validator Pod 在部署前校验节点环境是否满足 GPU 运行条件。
预检项目:
| 检查项 | 说明 |
|---|---|
| 内核版本 | 检查 Linux 内核≥3.10 |
| 内核头文件 | 检查 kernel-devel 安装 |
| GCC 版本 | 检查编译工具链 |
| 容器运行时 | 检查 containerd/cri-o/docker |
| SELinux 状态 | 检查 SELinux 是否阻止设备挂载 |
| GPU 硬件 | 通过 lspci 检查 NVIDIA GPU |
| GPU 驱动 | 检查 nvidia.ko 加载状态 |
| CUDA 库 | 检查 libcuda.so 版本 |
Validator 配置:
apiVersion: v1
kind: ConfigMap
metadata:
name: validator-config
data:
config.yaml: |
version: v1
flags:
precompiled: false
toolkitEnvEnabled: true
validator:
env:
- name: DISABLE_DEV_CHARACTER_CHECK
value: "false"
args:
- --no-driver
- --no-runtime
预检失败处理策略:
预检流程:
1. Validator Job 在每个 GPU 节点上执行
2. 不满足条件 → 节点标记为 gpu.nvidia.com/status=failed
3. 满足条件 → 节点标记为 gpu.nvidia.com/status=ready
4. ClusterPolicy 中可设置 validator.operator.cleanupFailed
自动重试间隔: 5 分钟
19 GPU Operator 如何处理 GPU 显存不足与 OOM 场景?
答案:
GPU Operator 通过 Device Plugin 和容器运行时配合,实现 GPU 显存的分配和 OOM 管理。
显存分配流程:
1. Pod 请求 nvidia.com/gpu: 1
2. Device Plugin 分配 GPU-0
3. 注入环境变量 NVIDIA_VISIBLE_DEVICES=GPU-xxx
4. 容器内 CUDA 应用独占 GPU-0
5. 容器内申请显存超出限制
6. CUDA API 返回 out of memory
7. 容器级别 OOM Kill(触发重启策略)
显存限制与监控:
# 显存监控告警规则
groups:
- name: gpu-memory
rules:
- alert: GPUOOMImminent
expr: DCGM_FI_DEV_FB_USED / (DCGM_FI_DEV_FB_FREE + DCGM_FI_DEV_FB_USED) > 0.95
for: 2m
labels:
severity: warning
annotations:
summary: "GPU XQOPEN $labels.gpu XQCLOSE 显存使用率超过 95%"
OOM 处理策略:
| 场景 | 处理方式 |
|---|---|
| 单容器 OOM | K8s OOMKiller 杀死容器,Pod 重启 |
| GPU 进程崩溃 | nvidia-smi 检测僵尸进程,Device Plugin 标记 GPU 异常 |
| 显存泄漏 | 监控持续增长,触发告警,重启工作负载 |
| 多容器争抢 | 每 GPU 独占分配,无法争抢共享显存 |
| XID 31 错误 | 显存页面故障,驱动层面隔离异常地址 |
20 GPU Operator 的 GPU Direct RDMA 支持
答案:
GPU Operator 通过 GPUDirect RDMA 实现 GPU 显存与网卡之间的直接数据传输,绕过 CPU 和系统内存。
GPUDirect RDMA 架构:
传统路径:
GPU → CPU Memory → NIC → Network
延迟: 高,CPU 参与拷贝
GPUDirect RDMA:
GPU → NIC(PCIe P2P)→ Network
延迟: 低,绕过 CPU
配置要求:
| 组件 | 要求 |
|---|---|
| GPU | A100/H100,支持 GPUDirect |
| 网卡 | NVIDIA ConnectX-6/7,支持 RDMA |
| 驱动 | nvidia-peer-memory 内核模块 |
| 拓扑 | GPU 和 NIC 在同一 PCIe Switch 下 |
| CUDA | CUDA 11.0+,启用 GPUDirect |
Operator 配置:
apiVersion: nvidia.com/v1
kind: ClusterPolicy
spec:
driver:
enabled: true
rdma:
enabled: true
useHostMofed: false
gpuDirect:
enabled: true
kernelModule:
name: nvidia-peer-memory
21 GPU Operator 与 Volcano 调度器的集成方案
答案:
GPU Operator 提供 GPU 资源注册,Volcano 实现 GPU 工作负载的批量调度和队列管理。
集成架构:
graph LR
subgraph GPU Operator
A[Device Plugin] --> A1[nvidia.com/gpu]
B[GFD] --> B1[节点标签]
C[MIG Manager]
end
subgraph Volcano
D[Queue<br/>GPU 队列]
E[PodGroup<br/>Gang Scheduling]
F[Job<br/>批量任务]
G[Scheduler<br/>拓扑感知]
end
Volcano 队列配置:
apiVersion: scheduling.volcano.sh/v1beta1
kind: Queue
metadata:
name: gpu-training-queue
spec:
weight: 1
capability:
nvidia.com/gpu: 32
apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
name: distributed-training
spec:
schedulerName: volcano
queue: gpu-training-queue
minAvailable: 8
tasks:
- replicas: 4
name: worker
template:
spec:
containers:
- name: pytorch
resources:
limits:
nvidia.com/gpu: 8
Gang Scheduling 策略:
分布式训练场景:
4 个 worker,每个需要 8 块 GPU
minAvailable: 4(4 个 worker 必须同时调度)
任一 worker 无法调度 → 整体等待
全部 worker 就绪 → 同时启动
22 GPU Operator 的 Topology-Aware 调度(NUMA/PCIe 亲和性)
答案:
GPU Operator 结合 Kubernetes Topology Manager 实现 NUMA 和 PCIe 拓扑感知调度。
拓扑策略:
| 策略 | 说明 |
|---|---|
| none | 不启用拓扑感知 |
| best-effort | 尽量满足拓扑约束 |
| restricted | 严格满足,不满足则拒绝调度 |
| single-numa-node | 所有资源必须在同一 NUMA 节点 |
Kubelet 拓扑管理配置:
# kubelet 配置
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
topologyManagerPolicy: single-numa-node
featureGates:
TopologyManager: true
Pod 拓扑约束:
apiVersion: v1
kind: Pod
metadata:
name: gpu-topology-pod
spec:
containers:
- name: training
resources:
limits:
nvidia.com/gpu: 4
memory: 128Gi
cpu: 32
requests:
nvidia.com/gpu: 4
memory: 128Gi
cpu: 32
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
23 GPU Operator 的 CRD(ClusterPolicy)详解
答案:
ClusterPolicy 是 GPU Operator 的核心 CRD,控制所有子组件的部署和配置。
ClusterPolicy 完整结构:
apiVersion: nvidia.com/v1
kind: ClusterPolicy
metadata:
name: cluster-policy
spec:
operator:
defaultRuntime: containerd
deployGFD: true
cleanupState:
driver: false
toolkit: true
validator:
plugin:
env:
- name: DISABLE_DEV_CHARACTER_CHECK
value: "false"
driver:
enabled: true
version: "535.154.05"
repoConfig:
configMapName: driver-repo-config
licensingConfig:
configMapName: licensing-config
virtualTopology:
config: ""
env: []
toolkit:
enabled: true
env:
- name: CONTAINERD_CONFIG
value: /etc/containerd/config.toml
devicePlugin:
enabled: true
config:
name: device-plugin-config
default: default
mig:
strategy: mixed
migManager:
enabled: true
config:
name: mig-manager-config
gfd:
enabled: true
dcgm:
enabled: true
dcgmExporter:
enabled: true
config:
name: dcgm-exporter-config
nodeStatusExporter:
enabled: false
gpuFeatureDiscovery:
enabled: true
sandboxDevicePlugin:
enabled: false
vgpuManager:
enabled: false
vgpuDeviceManager:
enabled: false
CRD 状态字段:
kubectl get clusterpolicy cluster-policy -o yaml
# status 字段展示各组件运行状态
# status.state: ready / notReady / ignored
24 GPU Operator 在裸金属与虚拟化环境的差异
答案:
GPU Operator 在裸金属和虚拟化环境中的部署存在关键差异,主要涉及 GPU 透传方式和驱动安装策略。
环境差异对比:
| 维度 | 裸金属 | 虚拟化(VMware/KVM) |
|---|---|---|
| GPU 透传 | 原生 PCIe | PCI Passthrough / vGPU |
| 驱动安装 | Driver DaemonSet 直接安装 | 宿主机预装驱动 |
| 内核模块 | 自动编译 nvidia.ko | 不需要(宿主机已加载) |
| 驱动版本管理 | Operator 管理 | 宿主机手动管理 |
| MIG 支持 | 完整支持 | 取决于虚拟化层 |
| GPUDirect RDMA | 完整支持 | 部分支持 |
| 性能损耗 | 无 | 1-3% |
裸金属 Driver DaemonSet:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nvidia-driver-daemonset
spec:
template:
spec:
hostPID: true
containers:
- name: nvidia-driver
securityContext:
privileged: true
env:
- name: NVIDIA_DRIVER_VERSION
value: "535.154.05"
- name: NVIDIA_DRIVER_SKIP_REBUILD
value: "false"
虚拟化环境配置:
# 虚拟化环境下跳过驱动安装
apiVersion: nvidia.com/v1
kind: ClusterPolicy
spec:
driver:
enabled: false # 使用宿主机预装驱动
validator:
driver:
env:
- name: DISABLE_DEV_CHARACTER_CHECK
value: "true"
25 GPU Operator 的 GPU 算力隔离机制
答案:
GPU Operator 通过 MIG 硬件分区和时间片调度实现 GPU 算力隔离。
算力隔离层级:
Level 1: MIG 硬件隔离(A100/H100)
GPU → 多个 GI(GPU Instance)
每个 GI → 独立的 SM、显存、缓存
隔离强度: 最高
Level 2: Time-Slicing 时间片隔离
GPU → 多容器时间片轮转
隔离强度: 中等
Level 3: vGPU 软件隔离
GPU → 多 VM 通过 GPU Manager 共享
隔离强度: 基础
Level 4: CUDA MPS(Multi-Process Service)
GPU → 单 Context 内多进程并发
隔离强度: 最低
MIG 算力分配示例:
apiVersion: v1
kind: ConfigMap
metadata:
name: mig-config
data:
config.yaml: |
version: v1
flags:
migEnabled: true
migConfigs:
gpu-node-1:
- devices: ["GPU-0", "GPU-1"]
migEnabled: true
migDeviceSpecs:
- devices:
- parentDevice: "GPU-0"
migProfile: "2g.20gb"
- parentDevice: "GPU-1"
migProfile: "3g.40gb"
算力隔离对比:
| 方案 | SM 隔离 | 显存隔离 | 缓存隔离 | 故障隔离 | 性能干扰 |
|---|---|---|---|---|---|
| MIG | 硬件 | 硬件 | 硬件 | 是 | 无 |
| Time-Slicing | 时间片 | 共享 | 共享 | 否 | 高 |
| vGPU | 软件 | 软件 | 共享 | 部分 | 中 |
| MPS | 无 | 共享 | 共享 | 否 | 极高 |
26 GPU Operator 的日志与诊断方法
答案:
GPU Operator 各组件输出结构化日志,配合 nvidia-smi 命令可完成 GPU 状态诊断。
组件日志定位:
| 组件 | 日志获取命令 |
|---|---|
| Operator | kubectl logs -n gpu-operator deploy/gpu-operator |
| Driver | kubectl logs -n gpu-operator daemonset/nvidia-driver-daemonset |
| Device Plugin | kubectl logs -n gpu-operator daemonset/nvidia-device-plugin-daemonset |
| DCGM Exporter | kubectl logs -n gpu-operator daemonset/nvidia-dcgm-exporter |
| GFD | kubectl logs -n gpu-operator daemonset/gpu-feature-discovery |
| MIG Manager | kubectl logs -n gpu-operator daemonset/nvidia-mig-manager |
| Validator | kubectl logs -n gpu-operator job/gpu-operator-validator |
GPU 状态诊断命令:
# GPU 基本信息
nvidia-smi
# GPU 拓扑
nvidia-smi topo -m
# GPU 进程
nvidia-smi pmon -c 1
# MIG 状态
nvidia-smi mig -lgi
nvidia-smi mig -lci
# GPU ECC 错误
nvidia-smi -q -d ECC
# GPU 温度与功耗
nvidia-smi -q -d TEMPERATURE,POWER
# 持久化模式
nvidia-smi -pm 1
# 锁定 GPU 频率
nvidia-smi -lgc 1530,1530
诊断清单:
1. 核对 nvidia-smi 是否正常输出
2. 检查 /dev/nvidia* 设备文件
3. 核对 nvidia.ko 内核模块加载
4. 检查 nvidia-container-toolkit 配置
5. 验证 Device Plugin 注册
6. 检查容器内 CUDA 可用性
27 GPU Operator 如何实现 GPU 数量弹性扩缩?
答案:
GPU Operator 的 Device Plugin 通过 ListAndWatch 机制自动感知节点 GPU 数量变化,实现动态扩缩。
GPU 弹性扩缩流程:
节点扩容:
1. 新 GPU 插入
2. 驱动重新扫描 PCIe 总线
3. nvidia-smi 检测到新 GPU
4. Device Plugin ListAndWatch 上报新数量
5. Kubelet 更新节点 allocatable 资源
6. 新 Pod 调度到节点
节点缩容:
1. GPU 故障或移除
2. Device Plugin 健康检测失败
3. 异常 GPU 从可用列表移除
4. 该 GPU 上 Pod 被驱逐
5. Kubelet 更新节点 capacity
GPU 动态发现配置:
apiVersion: v1
kind: ConfigMap
metadata:
name: device-plugin-config
data:
config.yaml: |
version: v1
flags:
migStrategy: mixed
failOnInitError: false
sharing:
timeSlicing:
resources:
- name: nvidia.com/gpu
replicas: 4
GPU 缩容时的 Pod 迁移策略:
apiVersion: apps/v1
kind: Deployment
spec:
replicas: 4
template:
spec:
containers:
- name: inference
resources:
limits:
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu.unhealthy
operator: Exists
effect: NoExecute
tolerationSeconds: 30
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
28 GPU Operator 的镜像仓库配置与离线部署
答案:
GPU Operator 支持私有镜像仓库配置,满足离线环境部署需求。
私有镜像仓库配置:
apiVersion: nvidia.com/v1
kind: ClusterPolicy
spec:
operator:
repository: private-registry.local/nvidia
driver:
repository: private-registry.local/nvidia
image: driver
version: "535.154.05"
toolkit:
repository: private-registry.local/nvidia
image: container-toolkit
devicePlugin:
repository: private-registry.local/nvidia
image: k8s-device-plugin
dcgmExporter:
repository: private-registry.local/nvidia
image: dcgm-exporter
gfd:
repository: private-registry.local/nvidia
image: gpu-feature-discovery
migManager:
repository: private-registry.local/nvidia
image: mig-manager
validator:
repository: private-registry.local/nvidia
image: gpu-operator-validator
镜像拉取密钥:
apiVersion: v1
kind: Secret
metadata:
name: nvidia-registry-secret
namespace: gpu-operator
type: kubernetes.io/dockerconfigjson
data:
.dockerconfigjson: <base64-encoded-config>
apiVersion: nvidia.com/v1
kind: ClusterPolicy
spec:
operator:
imagePullSecrets:
- nvidia-registry-secret
离线部署清单:
| 镜像组件 | 镜像路径 | 大小 |
|---|---|---|
| driver | nvcr.io/nvidia/driver:535.154.05-ubuntu22.04 | ~1.5GB |
| container-toolkit | nvcr.io/nvidia/k8s/container-toolkit:v1.14.0-ubuntu20.04 | ~300MB |
| device-plugin | nvcr.io/nvidia/k8s-device-plugin:v0.14.0 | ~150MB |
| dcgm-exporter | nvcr.io/nvidia/k8s/dcgm-exporter:3.1.0-ubuntu20.04 | ~400MB |
| gfd | nvcr.io/nvidia/gpu-feature-discovery:v0.8.0 | ~100MB |
29 GPU Operator 多架构(x86/ARM)兼容性
答案:
GPU Operator 支持 x86_64 和 ARM64(Grace Hopper)架构的 GPU 节点管理。
多架构镜像支持:
| 组件 | x86_64 | ARM64 |
|---|---|---|
| Driver | 完整支持 | Grace Hopper 专用 |
| Container Toolkit | 支持 | 支持 |
| Device Plugin | 支持 | 支持 |
| DCGM Exporter | 支持 | 支持 |
| GFD | 支持 | 支持 |
| MIG Manager | A100/H100 | Grace Hopper 不支持 MIG |
多架构混合集群:
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nvidia-device-plugin
spec:
template:
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/arch
operator: In
values:
- amd64
- arm64
containers:
- name: nvidia-device-plugin
image: nvcr.io/nvidia/k8s-device-plugin:v0.14.0
ARM64 特殊配置:
apiVersion: v1
kind: ConfigMap
metadata:
name: driver-config-arm64
data:
config.yaml: |
version: v1
flags:
driverVersion: "550.54.14"
image: "nvcr.io/nvidia/driver:550.54.14-grace-hopper-ubuntu22.04"
arch: "arm64"
30 GPU Operator 生产环境部署最佳实践
答案:
GPU Operator 生产部署需覆盖高可用、监控、资源规划、安全隔离和运维自动化五个维度。
部署架构最佳实践:
高可用配置:
- Operator Deployment replicas ≥ 2
- Device Plugin DaemonSet 每个 GPU 节点一个实例
- DCGM Exporter 作为 DaemonSet 部署
- MIG Manager 按需启用,灰度切换 MIG 配置
资源规划:
- Operator: CPU 200m, Memory 256Mi
- Device Plugin: CPU 100m, Memory 128Mi
- DCGM Exporter: CPU 200m, Memory 512Mi
- Driver DaemonSet: CPU 500m, Memory 1Gi
监控与告警配置:
| 告警规则 | 阈值 | 级别 |
|---|---|---|
| GPU 温度 > 85°C | 5 分钟持续 | critical |
| GPU 利用率 < 10% | 30 分钟持续 | warning |
| 显存使用 > 90% | 5 分钟持续 | warning |
| XID 错误 > 0 | 即时 | critical |
| ECC 错误 > 0 | 5 分钟持续 | warning |
| DCGM Exporter 不可达 | 5 分钟持续 | critical |
运维规范:
1. 驱动升级遵循分批灰度策略(10%→30%→100%)
2. GPU 节点维护前执行 drain 操作
3. 每季度审查 GPU 资源利用率报告
4. MIG 配置变更需在维护窗口内执行
5. 保持 GPU Operator 版本与驱动版本联动
6. 定期演练 GPU 故障场景下的 Pod 迁移
7. nvidia-smi 健康检查纳入巡检脚本
8. GPU 节点标签规范化管理
9. GPU 资源配额与 LimitRange 覆盖所有租户
10. GPU 审计日志集中收集