3. NVIDIA驱动与容器运行时

在 Kubernetes 集群中启用 GPU 资源调度，底层依赖三个核心环节：NVIDIA 内核驱动、容器运行时接口以及CUDA 基础镜像。任何一个环节的版本不匹配或配置错误，都会导致 GPU 无法被 Pod 识别或调度失败。本章从驱动安装约束开始，逐步深入到运行时配置与镜像选型，帮助你在集群层面建立稳定的 GPU 基础环境。

3.1 NVIDIA 驱动安装要求

NVIDIA 驱动是 GPU 与操作系统之间的桥梁。在 Kubernetes 节点上安装驱动时，需要同时满足内核版本、驱动版本与 CUDA 版本的兼容性约束。

3.1.1 驱动版本与内核版本匹配

NVIDIA 驱动以内核模块（nvidia.ko）的形式加载，必须与当前 Linux 内核版本严格匹配。驱动安装后，建议通过以下命令验证模块加载状态：

# 检查驱动模块是否加载
lsmod | grep nvidia

# 查看驱动版本
nvidia-smi | grep "Driver Version"

3.1.2 驱动版本与 CUDA 版本兼容性

驱动版本决定了支持的最高 CUDA 版本。下表列出常见驱动版本与 CUDA 版本的对应关系：

选型建议：优先选择 NVIDIA 官方 LTS（长期支持）驱动分支，例如 470 系列或 525 系列，避免使用 Beta 或快速迭代分支。

3.1.3 驱动安装方式对比

3.2 nvidia-docker2 与 containerd 配置

容器运行时需要能够将宿主机 GPU 设备挂载到容器内部。传统方案使用 nvidia-docker2，而 Kubernetes 1.24+ 默认使用 containerd，两者配置方式不同。

3.2.1 nvidia-docker2 配置（Docker 运行时）

如果集群仍使用 Docker 作为容器运行时，需要安装 nvidia-docker2 并配置 Docker daemon：

# 安装 nvidia-docker2
distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.repo | \
  sudo tee /etc/yum.repos.d/nvidia-docker.repo
sudo yum install -y nvidia-docker2

# 重启 Docker 服务
sudo systemctl restart docker

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

配置完成后，Docker 会自动将 --gpus 参数转换为设备挂载和 nvidia-container-runtime 调用。

3.2.2 containerd 配置（Kubernetes 默认运行时）

Kubernetes 1.24+ 默认使用 containerd，需要配置 nvidia-container-runtime 作为 containerd 的运行时 handler：

# 安装 nvidia-container-runtime
sudo yum install -y nvidia-container-runtime

# 编辑 containerd 配置文件 /etc/containerd/config.toml
# 在 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes] 下添加：
[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"

# 重启 containerd
sudo systemctl restart containerd

3.2.3 运行时配置对比

3.3 CUDA 基础镜像选择

CUDA 基础镜像决定了容器内可用的 CUDA 工具包版本和运行时库。选择不当会导致应用无法调用 GPU 或出现符号链接错误。

3.3.1 镜像标签体系

NVIDIA 官方提供多种 CUDA 镜像标签，常见分类如下：

3.3.2 选型原则

• 生产推理服务：优先使用 runtime 标签，包含推理所需的 cuBLAS 和 TensorRT 库，同时镜像体积适中。
• 训练任务：使用 devel 标签，因为训练框架（如 PyTorch、TensorFlow）需要 nvcc 编译自定义算子。
• 最小化镜像：如果应用仅依赖 cudart，可以使用 base 标签，但需自行安装其他 CUDA 库。

3.3.3 多阶段构建示例

推荐使用多阶段构建分离编译环境和运行环境：

# 第一阶段：编译
FROM nvidia/cuda:12.0.0-devel-ubuntu22.04 AS builder
COPY src/ /app/src
WORKDIR /app
RUN nvcc -o gpu_app src/main.cu

# 第二阶段：运行
FROM nvidia/cuda:12.0.0-runtime-ubuntu22.04
COPY --from=builder /app/gpu_app /usr/local/bin/
CMD ["gpu_app"]

这种方式将编译工具链隔离在构建阶段，最终镜像仅包含运行时库，体积减少约 60%。

3.4 整体架构关系

下图展示了驱动、运行时与镜像在 Kubernetes 节点上的协作关系：

从图中可以看出，GPU 硬件通过内核驱动暴露给操作系统，容器运行时负责将 GPU 设备挂载到容器内，而 CUDA 基础镜像提供应用所需的运行时库。任何一层的版本断裂都会导致 GPU 不可用。

3.5 配置验证清单

完成驱动安装和运行时配置后，建议按以下步骤逐层验证：

1. 宿主机验证：执行 nvidia-smi，确认驱动版本和 GPU 列表正常显示。
2. 运行时验证：使用 docker run --rm --gpus all nvidia/cuda:12.0-runtime nvidia-smi（Docker）或 crictl run（containerd）测试 GPU 容器启动。
3. Kubernetes 验证：部署一个请求 GPU 资源的 Pod，检查 kubectl logs 输出是否包含 GPU 信息。