📚 课程目录第4章 GPU虚拟化与容器化

4. GPU虚拟化与容器化

4.1 核心原理：从“物理共享”到“容器隔离”

GPU虚拟化与容器化的本质，是解决“一块物理GPU如何被多个任务安全、高效地使用”的问题。传统物理机直接使用GPU时，一个进程独占整卡，利用率往往不足30%。而虚拟机透传（PCIe Passthrough）虽然隔离性好，但每台VM必须绑定整张卡，且启动重量级、管理复杂。容器化则提供了一条更轻量的路径：共享宿主机内核，通过命名空间（Namespace）隔离资源视图，通过控制组（Cgroups）限制资源用量。

NVIDIA Container Toolkit（原nvidia-docker）的核心组件包括：

nvidia-container-cli：负责在容器启动时注入GPU设备节点、驱动库和NVML（NVIDIA Management Library）句柄。
nvidia-container-runtime：作为Docker的运行时钩子（OCI Runtime），在runC创建容器前调用CLI完成GPU环境装配。
LD_LIBRARY_PATH与设备节点映射：容器内进程通过标准CUDA运行时库访问GPU，无需感知底层物理拓扑。

下图展示了从用户请求到GPU资源分配的核心链路，以及Kubernetes调度器如何介入这一过程：

图中红色链路是GPU资源真正“落地”的路径。Kubernetes调度器只负责在Pod调度时检查节点上是否有足够的nvidia.com/gpu资源，而真正的设备注入发生在容器运行时阶段。理解这一分工，是后续排查“调度成功但启动失败”类问题的关键。

4.2 方法流程：Docker与Kubernetes两套接入路径

4.2.1 Docker单机场景：三步接入GPU

在尚未引入Kubernetes的GPU服务器上，使用Docker直接运行GPU容器是最常见的起步方式。完整流程如下：

安装驱动与CUDA：宿主机安装NVIDIA驱动（建议≥470），并验证nvidia-smi输出正常。
安装NVIDIA Container Toolkit：配置APT源后安装nvidia-container-toolkit，并重启Docker服务。
验证运行时：执行docker run --rm --gpus all nvidia/cuda:12.2-base nvidia-smi，确认容器内可见GPU。

# 安装NVIDIA Container Toolkit（Ubuntu/Debian示例）
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \
  sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo systemctl restart docker

# 验证GPU容器
docker run --rm --gpus all nvidia/cuda:12.2-base nvidia-smi

生产环境中，建议显式指定GPU数量而非使用all：

docker run --rm --gpus '"device=0,1"' \
  -v /data:/data \
  --shm-size=8g \
  nvidia/cuda:12.2-base nvidia-smi

4.2.2 Kubernetes集群场景：设备插件与调度扩展

Kubernetes本身并不认识GPU，需要通过NVIDIA Device Plugin将节点上的GPU资源上报为可调度的扩展资源。部署流程如下：

步骤	操作	关键命令/配置
1. 节点打标	标记GPU节点	`kubectl label node gpu-node-01 nvidia.com/gpu.present=true`
2. 部署DaemonSet	安装Device Plugin	`kubectl apply -f nvidia-device-plugin.yml`
3. 验证资源上报	检查节点可分配资源	`kubectl describe node gpu-node-01 \| grep nvidia`
4. 创建GPU Pod	在Pod中声明GPU	resources.limits.nvidia.com/gpu: "1"

Device Plugin的核心逻辑是：启动时调用NVIDIA Management Library枚举物理GPU，然后通过Kubelet的DevicePlugin gRPC接口上报设备ID和健康状态。调度器在Pod调度时看到nvidia.com/gpu的请求量，会将其绑定到满足条件的节点上。

4.3 案例实战：从Pod YAML到实际运行

以下是一个标准的GPU推理服务部署示例，包含资源声明、环境变量和健康检查：

apiVersion: v1
kind: Pod
metadata:
  name: gpu-inference-demo
spec:
  containers:
  - name: triton-server
    image: nvcr.io/nvidia/tritonserver:23.10-py3
    command: ["/bin/bash", "-c"]
    args:
      - |
        tritonserver \
          --model-repository=/models \
          --http-port=8000
    resources:
      limits:
        nvidia.com/gpu: 1    # 关键：声明需要1张GPU
        memory: "16Gi"
        cpu: "8"
    env:
    - name: NVIDIA_VISIBLE_DEVICES
      value: "0"             # 可选：指定物理GPU编号
    volumeMounts:
    - name: model-storage
      mountPath: /models
    livenessProbe:
      httpGet:
        path: /v2/health/live
        port: 8000
      initialDelaySeconds: 30
  volumes:
  - name: model-storage
    persistentVolumeClaim:
      claimName: model-pvc

部署后，可通过以下命令验证GPU是否真正被容器使用：

# 查看Pod调度到了哪个节点
kubectl get pod gpu-inference-demo -o wide

# 进入容器查看GPU状态
kubectl exec -it gpu-inference-demo -- nvidia-smi

# 查看容器实际使用的GPU编号
kubectl exec -it gpu-inference-demo -- \
  bash -c "echo $CUDA_VISIBLE_DEVICES"

一个常见误区是：在Pod中设置NVIDIA_VISIBLE_DEVICES=0就以为绑定了物理GPU 0。实际上，该环境变量在容器运行时阶段才会被读取，且编号是相对于容器可见设备列表的索引，而非宿主机物理编号。若需精确绑定，应使用Device Plugin的nvidia.com/gpu资源配额，而非手动指定设备号。

4.4 误区与复盘：GPU容器化运维的五个深坑

坑位1：驱动版本与容器镜像不匹配
宿主机驱动为470，但容器镜像基于CUDA 12.2（要求驱动≥525），导致容器内应用报CUDA driver version is insufficient。复盘：CUDA运行时向后兼容，但驱动必须≥镜像要求的最低版本。排查时先执行nvidia-smi查看驱动版本，再对比镜像的CUDA要求。

坑位2：忘记设置共享内存
多进程数据加载（如PyTorch DataLoader）需要较大/dev/shm，默认64MB会导致崩溃。解决：在Pod中设置emptyDir挂载到/dev/shm，或Docker运行时加--shm-size=8g。

坑位3：MIG模式与Device Plugin不兼容
开启MIG（多实例GPU）后，旧版Device Plugin无法识别MIG设备。需使用支持MIG的插件版本，并在配置中启用mig.strategy=mixed。否则调度器会认为节点无GPU资源。

坑位4：容器内nvidia-smi显示“No devices”
可能原因：容器运行时未正确注入设备节点。检查/dev/nvidia*是否存在，以及nvidia-container-cli info输出。若使用Rootless Docker，需额外配置--gpus的权限模型。

坑位5：GPU显存泄漏导致OOM
容器内进程退出后显存未释放，长时间运行后节点可用显存归零。复盘：使用nvidia-smi --query-gpu=memory.used --format=csv监控，配合fuser -v /dev/nvidia*定位残留进程，必要时配置NVIDIA_DRIVER_CAPABILITIES=all并启用ECC页回收。

4.5 生产环境建议清单

统一镜像基线：基于nvidia/cuda:12.2-base构建，避免每个团队各自拉取不同CUDA版本。
资源配额强制化：在Kubernetes的LimitRange中设置nvidia.com/gpu的默认请求与上限，防止超卖。
GPU监控集成：部署DCGM-Exporter采集GPU利用率、温度、显存带宽等指标，接入Prometheus告警。
定期执行GPU健康检查：使用nvidia-smi -q -d HEALTH或DCGM诊断套件，在节点加入集群前验证GPU状态。
容器内禁止安装驱动：容器共享宿主机内核模块，安装驱动会覆盖/usr/lib/x86_64-linux-gnu/libcuda.so导致运行时崩溃。

GPU容器化的核心价值在于将“物理卡资源”抽象为“可调度的逻辑配额”，但底层仍然依赖驱动、CUDA运行时和设备节点的正确协作。运维人员需要同时理解容器运行时机制和NVIDIA驱动栈，才能在故障发生时快速定位是调度层、运行时层还是驱动层的问题。建议在测试环境完整演练一次从驱动安装到Pod运行的流程，并记录每一步的验证命令，形成团队内部的GPU容器化运维手册。