服务器K8s集群GPU算力隔离：多用户共享显卡实操配置

在Kubernetes集群里让多个Pod共享同一块GPU时，默认行为是整卡独占：一个Pod申请了nvidia.com/gpu: 1，其他Pod就无法再调度到这张卡上。
如果业务需要多人共用显卡，就必须做GPU算力隔离。
本文按零基础可执行的顺序，讲清楚准备条件、两种主流隔离方案的操作步骤、验证方式和常见报错处理。

先确认你的环境能不能做隔离

GPU算力隔离不是纯软件配置，它依赖硬件型号和驱动能力。
动手前先核对三件事：

• GPU型号：NVIDIA A100、A30、H100等支持MIG（Multi-Instance GPU，把一张物理卡切成多个独立小卡）的型号，才能做硬件级显存与算力隔离；消费级卡如RTX 3090、4090通常不支持MIG。
• 驱动与CUDA版本：在节点执行nvidia-smi，确认驱动正常加载，并记录驱动版本。MIG需要较新的驱动和CUDA版本，具体支持范围以NVIDIA官方文档为准。
• Kubernetes版本：建议1.20以上，节点已安装nvidia-container-toolkit，容器运行时（Docker或containerd）已配置为使用NVIDIA运行时。

如果节点上nvidia-smi都跑不起来，先修驱动，不要继续往下做。

安装NVIDIA Device Plugin并确认显卡可被调度

K8s本身不认识GPU，需要Device Plugin把GPU资源上报给kubelet。
推荐用Helm安装官方插件：

helm repo add nvdp https://nvidia.github.io/k8s-device-plugin
helm repo update
helm install nvdp nvdp/nvidia-device-plugin \
  --namespace kube-system \
  --set migStrategy=mixed

migStrategy=mixed表示同时暴露整卡和MIG实例，适合后面做切分。
安装后验证：

kubectl get nodes -o json | grep nvidia.com/gpu
kubectl describe node <节点名> | grep -A5 Capacity

如果Capacity里出现nvidia.com/gpu，说明插件生效。
若为空，检查节点是否打了污点、DaemonSet是否Running、/var/lib/kubelet/device-plugins目录权限是否正常。

方案一：用MIG做硬件级算力隔离

MIG把一张A100切成最多7个独立实例，每个实例有专属显存和计算单元，隔离性最好，适合对稳定性要求高的多租户场景。

在节点上启用MIG并创建实例（需要先停止该卡上的业务）：

sudo nvidia-smi -i 0 -mig 1
sudo nvidia-smi mig -cgi 1g.5gb,1g.5gb -C

上面命令在0号卡上创建两个1g.5gb实例。
创建后用nvidia-smi -L确认实例UUID。
然后在Pod里通过资源名申请，例如nvidia.com/mig-1g.5gb: 1。

注意：MIG实例的切分比例受型号限制，不是任意组合，切分前先查该型号支持的Profile列表。

方案二：用时间片共享做软隔离

如果显卡不支持MIG，或者只需要让多个轻量任务轮流用卡，可以用时间片共享。
Device Plugin支持配置共享数量：

# 在helm values中设置
config:
  map:
    default: |-
      version: v1
      sharing:
        timeSlicing:
          resources:
            - name: nvidia.com/gpu
              replicas: 4

这样一张卡会被上报为4个可用资源，4个Pod可同时调度。
但要注意：时间片共享不隔离显存，一个Pod显存溢出会影响同卡其他Pod，只适合任务互信、负载可控的场景。

验证隔离是否生效

部署两个测试Pod，分别申请GPU资源，然后进入容器执行：

kubectl exec -it  -- nvidia-smi

MIG方案下，每个Pod的nvidia-smi应只看到分配给自己的实例，显存上限与Profile一致。
时间片方案下，多个Pod会看到同一张整卡，但能同时运行。

同时观察节点：

kubectl describe node <节点名> | grep -A10 Allocated

确认已分配资源数符合预期。

容易踩的坑

• 驱动版本不匹配：宿主机驱动、容器内CUDA、Device Plugin三者版本差异过大时，Pod会报no NVIDIA devices found。优先统一驱动版本。
• 忘记重启kubelet：改完容器运行时配置后不重启kubelet和容器运行时，GPU资源不会重新上报。
• MIG切换需要清空任务：对已运行任务的卡做MIG切分可能失败，操作前先排空节点。
• 时间片共享不等于资源保障：它只是让多个Pod排队使用，不能防止算力抢占，生产环境慎用。
• 显存限制不能靠K8s：K8s只调度GPU数量，不限制容器内显存用量，显存隔离要靠MIG或应用自身控制。

常见疑问

没有MIG的显卡能不能做算力隔离？
不能做硬件级隔离，只能用时间片共享让多个Pod轮流使用。真正要隔离算力，需要换支持MIG的型号。

MIG实例切多了会不会影响性能？
每个实例的计算单元是独立划分的，单个实例性能会低于整卡，但实例之间互不干扰。切分比例要按业务实际负载决定。

Pod申请了GPU但一直Pending怎么办？
先看kubectl describe pod事件，常见原因是节点GPU资源已被占满、节点有污点未容忍、或Device Plugin未正常上报资源。

GPU算力隔离的核心是先确认硬件能力，再选MIG或时间片方案。
硬件支持时优先MIG，隔离性和稳定性更好；
硬件不支持时时间片共享只能解决“能用”，解决不了“互不影响”。
配置完成后务必用测试Pod验证资源视图，再上生产业务。