- 引言 — 摆脱 GPU 节点搭建的地狱
- GPU Operator 部署了什么
- 安装 — 一个 Helm Chart 搞定
- 验证 — Pod 里能看到 GPU 吗
- MIG — 在硬件层面切分一张 GPU
- MIG 策略 — single vs mixed
- 应用 MIG — 一个节点标签搞定
- 自定义 Profile — 在一张卡内混合尺寸
- 运维注意事项 — 提前知道就不算故障
- 结语
- 参考资料
引言 — 摆脱 GPU 节点搭建的地狱
在 Kubernetes 集群里手动接入过 GPU 节点的人都懂。要把 NVIDIA 驱动装成和内核版本匹配的版本,装上 container toolkit,改运行时配置,部署设备插件,再接上监控 exporter——这五层的版本适配只要有一层没对上,Pod 就看不到 GPU。节点有 10 台,这套动作就要做 10 遍;内核一升级,又得从头再来。
NVIDIA GPU Operator 用 Kubernetes 的 Operator 模式把这整套栈自动化了。管理员只需安装一个 Helm Chart,声明期望状态,Operator 就会把各个节点所需的组件以容器形式部署上去,并持续 reconcile。本文将从安装、验证,一路讲到 A100/H100 级 GPU 的杀手级功能——MIG(Multi-Instance GPU)分区配置——全程配合实际命令。如果需要先补一下 Kubernetes 基础,也可以先去本站的 Kubernetes 游乐场找找感觉。
GPU Operator 部署了什么
安装 Operator 之后,gpu-operator 命名空间下会以 DaemonSet 的形式部署以下这些 operand。每一个都对应着手动搭建时代里手工做的一件事。
- NVIDIA Driver(容器化) — 不直接在宿主机上装驱动,而是通过容器加载内核模块。应对内核升级会变得极其轻松。
- NVIDIA Container Toolkit — 让容器运行时能够把 GPU 暴露给 Pod。
- Device Plugin — 向 Kubernetes 调度器广播
nvidia.com/gpu资源。 - GPU Feature Discovery(GFD) — 把 GPU 型号、显存、MIG 状态发布为节点标签,可用于节点选择器。
- DCGM Exporter — 把 GPU 利用率、显存、温度、功耗导出为 Prometheus 指标。
- MIG Manager — 本文的主角。监听节点标签,一旦变化就把 MIG 分区实际应用到硬件上。
- Validator — 运行验证作业,检查每个环节是否正常工作。
安装 — 一个 Helm Chart 搞定
前提条件有三个:装有 NVIDIA GPU 的节点、受支持的容器运行时(containerd 等),以及 Node Feature Discovery(Operator 默认会一并安装)。
# 1) 添加 NVIDIA Helm 仓库
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update
# 2) 安装(版本请以官方文档最新为准 —— 本文写作时为 v26.3.3)
helm install --wait gpu-operator \
-n gpu-operator --create-namespace \
nvidia/gpu-operator \
--version=v26.3.3
根据环境不同,常见的两种变体:
# 如果节点上已经装好驱动(DGX OS、手动安装等场景)
helm install --wait gpu-operator \
-n gpu-operator --create-namespace \
nvidia/gpu-operator \
--version=v26.3.3 \
--set driver.enabled=false
# 如果 container toolkit 也已经装好,再加上:
# --set toolkit.enabled=false
确认安装状态:
kubectl get pods -n gpu-operator
# driver-daemonset、container-toolkit、device-plugin、dcgm-exporter、
# gpu-feature-discovery、operator-validator 全部为 Running/Completed 即正常
验证 — Pod 里能看到 GPU 吗
最可靠的验证方式,是用一个申请 GPU 的测试 Pod。
apiVersion: v1
kind: Pod
metadata:
name: gpu-smoke-test
spec:
restartPolicy: Never
containers:
- name: nvidia-smi
image: nvidia/cuda:12.4.1-base-ubuntu22.04
command: ['nvidia-smi']
resources:
limits:
nvidia.com/gpu: 1
kubectl apply -f gpu-smoke-test.yaml
kubectl logs gpu-smoke-test
# nvidia-smi 输出里能看到 GPU 型号即成功
顺便确认一下 GFD 打上的节点标签,写节点选择器时会用得上:
kubectl get node <节点名> -o jsonpath='{.metadata.labels}' | jq . | grep nvidia
# nvidia.com/gpu.product、nvidia.com/gpu.memory、nvidia.com/gpu.count 等
MIG — 在硬件层面切分一张 GPU
像 A100/H100 这样的数据中心 GPU,单卡往往太大了。一个小型推理负载独占一张 80GB 的 GPU,剩下的容量就白白闲置。MIG(Multi-Instance GPU)是从 Ampere 世代开始支持的功能,能把一张 GPU 最多切分成 7 个硬件隔离的实例。
关键在于"硬件隔离"。每个 MIG 实例都会物理分配到属于自己的一份 SM(计算单元)、L2 缓存和显存带宽。这正是它和时分复用(time-slicing)的决定性区别——时分复用是多个 Pod 轮流使用同一张 GPU,所以一个 Pod 的突发负载会波及另一个 Pod 的延迟;而 MIG 无论邻居实例在做什么,自己的性能都有保证。这也是多租户集群、推理服务、按团队分配 GPU 场景偏爱 MIG 的原因。
Profile 名称遵循 <GI 数量>g.<显存>gb 的格式。比如一张 H100 80GB,典型的切分方式是这样:
Profile 实例数(最多) 大致用途
1g.10gb ×7 7 个小型推理
2g.20gb ×3 3 个中型推理/实验
3g.40gb ×2 2 个中大型训练
7g.80gb ×1 不切分,整卡使用
(也可以混合:例如 3g.40gb 1 个 + 2g.20gb 1 个 + 1g.10gb 2 个)
A100 40GB 也是同样的原理,会变成 1g.5gb×7、2g.10gb×3、3g.20gb×2……。具体的组合规则因 GPU 型号而异,请以 NVIDIA MIG 用户指南里的 Profile 表为准。
MIG 策略 — single vs mixed
要在 GPU Operator 里使用 MIG,首先得在安装时定好 策略(strategy)。这个选择会改变资源向 Kubernetes 广播的方式。
- single — 节点上所有 GPU 都启用 MIG,并且全部使用同一个 Profile。资源仍然以熟悉的
nvidia.com/gpu名称广播,只是数量增多(例如:1 张 H100 →nvidia.com/gpu: 7)。不需要改动 Pod spec,是最容易落地的方式。 - mixed — 同一节点内可以共存不同的 Profile(甚至包括未启用 MIG 的 GPU)。资源按 Profile 分别广播(例如
nvidia.com/mig-1g.10gb、nvidia.com/mig-3g.40gb)。更灵活,但 Pod 必须明确指定 Profile。
# 以 single 策略安装
helm install --wait gpu-operator \
-n gpu-operator --create-namespace \
nvidia/gpu-operator \
--version=v26.3.3 \
--set mig.strategy=single
# 如果是像 GKE/EKS 这类需要重启的云环境,再加上:
# --set migManager.env[0].name=WITH_REBOOT \
# --set-string migManager.env[0].value=true
如果只想在已安装的集群上改变策略,可以 patch ClusterPolicy:
kubectl patch clusterpolicies.nvidia.com/cluster-policy \
--type='json' \
-p='[{"op":"replace", "path":"/spec/mig/strategy", "value":"mixed"}]'
应用 MIG — 一个节点标签搞定
MIG Manager 的工作原理简单得优雅:监听 nvidia.com/mig.config 节点标签,标签一变,就把对应的 Profile 应用到硬件上。
# 把一台 H100 节点切分成 7 个 1g.10gb
kubectl label nodes <节点名> nvidia.com/mig.config=all-1g.10gb --overwrite
内置的 Profile 包括 all-disabled(关闭 MIG)、all-1g.10gb、all-2g.20gb、all-3g.40gb、all-balanced(多种尺寸均衡混合)等。应用过程可以通过标签追踪:
kubectl get node <节点名> -o jsonpath='{.metadata.labels}' | jq . | grep mig
# nvidia.com/mig.config.state 依次经过
# pending → (如有需要则 rebooting) → success 即完成
success 之后确认资源,就能看到切分结果:
kubectl describe node <节点名> | grep -A5 'Allocatable'
# single 策略: nvidia.com/gpu: 7 (标签中的 gpu.product 会显示 MIG-1g.10gb)
# mixed 策略: nvidia.com/mig-1g.10gb: 7 这样按 Profile 划分的资源
在 mixed 策略下,Pod 会像这样指定具体 Profile:
resources:
limits:
nvidia.com/mig-1g.10gb: 1
自定义 Profile — 在一张卡内混合尺寸
如果内置 Profile 不够用(比如"只有 0 号 GPU 需要 3g+1g+1g 混合,其余关闭 MIG"),可以用 ConfigMap 直接定义。
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-mig-config
namespace: gpu-operator
data:
config.yaml: |
version: v1
mig-configs:
all-disabled:
- devices: all
mig-enabled: false
inference-mix:
- devices: [0]
mig-enabled: true
mig-devices:
"1g.10gb": 5
"2g.20gb": 1
- devices: [1, 2, 3]
mig-enabled: false
# 让 MIG Manager 使用这个 ConfigMap,需要 patch ClusterPolicy
kubectl patch clusterpolicies.nvidia.com/cluster-policy \
--type='json' \
-p='[{"op":"replace", "path":"/spec/migManager/config/name", "value":"custom-mig-config"}]'
# 把自定义 Profile 应用到节点
kubectl label nodes <节点名> nvidia.com/mig.config=inference-mix --overwrite
另外,从 v26.3.0 开始,MIG Manager 会在启动时通过 NVML 查询节点硬件,在运行时自动生成可用的 Profile 列表,并写成每个节点各自的 ConfigMap。这样一来,新的 GPU 型号发布后,也不用再等内置 Profile 列表更新了。
运维注意事项 — 提前知道就不算故障
- 重新配置是破坏性操作。 MIG Manager 在改变 Profile 之前,会先停掉该 GPU 上的所有 Pod(包括设备插件、DCGM、GFD)。如果节点上跑着用户负载,先 cordon + drain 才是安全的操作流程。
- 云上有可能需要重启。 部分 CSP 环境切换 MIG 模式需要重启节点——前面提到的
WITH_REBOOT设置就是为此准备的。mig.config.state经过rebooting是正常流程。 - Pod 不能跨实例使用。 一个 MIG 实例就是一个 Pod 的上限。如果预计会有需要 7g Profile 的大型训练任务,请提前准备 mixed 策略或单独的节点池。实例之间也无法使用 NVLink P2P。
- 状态卡在
pending时,先看 MIG Manager 的 Pod 日志。常见原因:标签打错了(引用了不存在的 Profile 名),该 GPU 不支持这种 Profile 组合,或者还有 Pod 占着这块 GPU 没释放。 - 监控用 DCGM。 DCGM Exporter 会输出以 MIG 实例为单位的指标,所以在 Prometheus 里能直接看到每个实例的利用率、显存占用。找出"切分了却在闲置"的实例,是 MIG 运维的后半程工作。
- 和时分复用的取舍:需要隔离性和可预测性就用 MIG;目标是超售(想办法多塞几个 Pod 进去)且能容忍相互干扰,就用 time-slicing——两者的目的本就不同。
结语
GPU Operator 把"搭建 GPU 节点"这项重复劳动变成了一个声明式资源,MIG Manager 又在此基础上让昂贵 GPU 的利用率问题只靠一行标签就能处理。归纳一下:用 Helm 安装,定策略(single/mixed),用 nvidia.com/mig.config 标签分区,用 mig.config.state 确认,用 DCGM 观察——这五句话就是全部。剩下的,就是为你自己的负载找到合适的 Profile,而这件事,监控数据会告诉你答案。
如果想顺便打牢 Linux 和 Kubernetes 的基础,也可以用一下 Linux 终端和 Kubestronaut 测验。