4、Docker与NVIDIA Container Toolkit：安装配置、nvidia-docker2与nvidia-container-toolkit的区别与演进

在Edge AI场景中，GPU加速容器化部署的核心挑战在于：如何让容器内的CUDA应用安全、高效地访问宿主机上的NVIDIA GPU设备。早期方案依赖nvidia-docker2插件，而当前主流方案已演进为nvidia-container-toolkit。理解两者的区别与演进逻辑，是配置容器GPU权限与设备映射的基础。本章将深入剖析其工作原理、安装配置方法、版本差异及实战中的关键决策点。

上图展示了从nvidia-docker2到nvidia-container-toolkit的演进路径。左侧为传统方案，右侧为当前推荐方案，中间核心组件层展示了工具链的构成。理解这一演进过程，有助于在Edge AI设备上正确选择安装包和配置运行时。

4.1 核心原理：从Docker插件到OCI运行时钩子

nvidia-docker2是NVIDIA早期提供的Docker插件，其工作原理是：通过修改Docker daemon配置，注册一个名为nvidia的运行时（runtime）。当用户使用--runtime=nvidia启动容器时，该运行时会调用nvidia-container-runtime，进而通过nvidia-container-cli完成GPU设备注入、驱动库挂载和CUDA环境配置。这一方案的问题在于：它深度耦合Docker，且需要用户显式指定runtime，无法透明地支持Kubernetes、Podman等其他容器运行时。

nvidia-container-toolkit则采用了更现代的OCI（Open Container Initiative）运行时钩子机制。它不再要求用户指定runtime，而是通过配置Docker/containerd的runtimes参数，将nvidia-container-runtime注册为默认或备用运行时。当容器请求GPU资源时（通过环境变量NVIDIA_VISIBLE_DEVICES），工具链自动完成设备映射。其核心组件包括：

• libnvidia-container：底层C库，负责GPU设备发现、驱动库解析和命名空间隔离。
• nvidia-container-cli：命令行工具，用于在容器启动前执行设备注入操作。
• nvidia-container-runtime：OCI运行时包装器，兼容Docker、containerd、CRI-O等。
• nvidia-container-toolkit：高层配置工具，自动生成运行时配置并集成到容器引擎中。

4.2 安装配置：从零到可用的完整流程

在Edge AI设备（如Jetson系列或x86工控机）上安装NVIDIA Container Toolkit，需要遵循以下步骤。以Ubuntu 20.04/22.04 LTS为例：

1. 检查驱动与CUDA环境：确保宿主机已安装NVIDIA驱动，运行nvidia-smi确认GPU可见。
2. 添加NVIDIA官方仓库：

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

3. 安装工具包：

sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit

4. 配置Docker运行时：

sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

5. 验证安装：

docker run --rm --gpus all nvidia/cuda:12.0-base nvidia-smi

对于containerd环境（Kubernetes节点），使用sudo nvidia-ctk runtime configure --runtime=containerd，然后重启containerd。注意：在Jetson设备上，由于驱动架构不同（使用JetPack SDK），安装方式略有差异，通常直接通过apt install nvidia-container-toolkit即可，但需确保JetPack版本与CUDA容器兼容。

4.3 案例拆解：Edge AI设备上的GPU容器化部署

背景与约束：某工业视觉检测项目需要在NVIDIA Jetson AGX Orin设备上部署多个AI推理容器，分别运行目标检测、图像分类和异常检测模型。设备资源受限（GPU显存32GB，CPU 12核），且需支持热更新模型版本。初始方案使用nvidia-docker2，但遇到两个问题：一是Kubernetes集群无法识别GPU资源；二是容器启动时经常报nvidia-container-cli: initialization error。

分析判断过程：通过docker info查看运行时列表，发现nvidia运行时存在但未被Kubernetes使用。进一步检查/etc/docker/daemon.json，发现配置了"default-runtime": "nvidia"，但Kubernetes的kubelet使用containerd作为运行时，导致GPU资源无法上报。同时，nvidia-container-cli初始化错误通常是因为驱动版本与容器内CUDA版本不匹配，或设备节点权限不足。

实际操作步骤：

1. 卸载nvidia-docker2，安装nvidia-container-toolkit：sudo apt remove nvidia-docker2 && sudo apt install nvidia-container-toolkit。
2. 配置containerd运行时：sudo nvidia-ctk runtime configure --runtime=containerd，然后重启containerd。
3. 在Kubernetes节点上部署NVIDIA device plugin：kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/main/nvidia-device-plugin.yml。
4. 修改容器启动命令，移除--runtime=nvidia，改用--gpus all，并设置NVIDIA_DRIVER_CAPABILITIES=compute,utility。
5. 验证GPU资源：kubectl describe node | grep nvidia，确认可分配GPU数量正确。

结果对比：迁移后，Kubernetes正确识别了8个GPU设备（Orin的GPU被划分为多个实例），容器启动时间从平均15秒降至8秒，且未再出现初始化错误。模型热更新通过滚动重启Deployment实现，每个容器独立分配GPU显存，互不干扰。

风险与代价：迁移过程中需注意：containerd配置修改后，所有现有容器需重建才能生效；device plugin的版本需与Kubernetes版本兼容；在Jetson设备上，需确保JetPack 5.0+，否则nvidia-ctk可能无法识别GPU。

4.4 常见误区与总结复盘

误区一：认为nvidia-docker2是唯一方案。实际上，NVIDIA官方已停止维护nvidia-docker2，新项目应直接使用nvidia-container-toolkit。在Edge AI场景中，由于Kubernetes和轻量级容器运行时（如containerd）的普及，工具链的兼容性至关重要。

误区二：混淆NVIDIA_VISIBLE_DEVICES与--gpus参数。NVIDIA_VISIBLE_DEVICES是环境变量，用于控制容器内可见的GPU设备编号；--gpus是Docker CLI参数，两者作用相同但语法不同。在Kubernetes中，通过device plugin自动设置该环境变量，无需手动指定。

误区三：忽略驱动版本匹配。容器内的CUDA版本必须与宿主机驱动兼容。例如，驱动版本535.x支持CUDA 12.2，但若容器使用CUDA 12.0，则可能因缺少libcuda.so.1而失败。建议使用nvidia-smi查看驱动支持的CUDA版本，并选择对应的基础镜像。

误区四：在Jetson设备上使用x86的安装源。Jetson设备使用ARM架构，需使用NVIDIA为JetPack定制的仓库。错误使用x86源会导致安装失败或运行时崩溃。