第 4 课：容器、驱动、Device Plugin 与升级兼容性

参考答案版：包含完整代码实现与问答题深度参考解析。建议先独立完成练习题后再展开核对。

本课目标与完成标准

本课产出：实现组件版本区间的兼容性检查，并解释 GPU 设备从节点到容器的分配链。

通过要求：唯一代码填空题通过给定检查；Q1～Q3 都给出因果链；能指出一个正确性边界和一个性能/运营取舍；总分至少 8/10。

与既有六条主线的边界

本课不教 Kubernetes 命令清单；重点是 host driver、container runtime、device plugin、CUDA user-space 和作业镜像之间的责任边界。

前置：Linux/网络基础、runtime 补充线、train 分布式章节。本课只补 AI Infra 缺口，不重复已经完成的 kernel 或并行算法推导。

核心心智模型

1. 它是什么，解决什么问题

在云原生 AI 算力平台中，平台工程师面临的核心挑战是：如何将物理宿主机上极其复杂的英伟达 GPU 硬件生态（包含底层内核模块、微码固件、Fabric Manager、专有驱动、NVML 监控库）安全、弹性且透明地交付给成千上万个运行在 Kubernetes Pod 容器中的深度学习应用（如 PyTorch、vLLM、Megatron-LM）？

传统容器技术与 GPU 硬件直通之间存在本质上的架构分层矛盾（如图 4-1 所示）：

flowchart TD
    subgraph HostOS["宿主机环境 (Host OS)"]
        Kernel["Linux 内核"]
        Driver["NVIDIA 驱动 (nvidia.ko)"]
        Toolkit["nvidia-container-toolkit"]
    end
    subgraph K8s["Kubernetes 集群调度"]
        Kubelet["Kubelet 节点守护进程"]
        DevPlugin["NVIDIA K8s Device Plugin"]
    end
    subgraph Container["应用容器 (Pod Container)"]
        CUDA["CUDA Runtime (libcudart)"]
        PyTorch["PyTorch / AI 训练推理框架"]
    end
    DevPlugin -->|向 Kubelet 上报 nvidia.com/gpu 资源| Kubelet
    Toolkit -->|挂载驱动字符设备 /dev/nvidia*| Container

图 4-1：NVIDIA 容器运行时生态与 K8s Device Plugin 分层交互拓扑

Linux 容器（如 Docker、containerd）本质上是基于 Linux 内核 Namespace（PID、Mount、Network）与 Cgroups 实现的轻量级进程隔离，所有容器共享宿主机内核（Host Kernel）；
GPU 是高度专用的硬件外设，其驱动分为运行在 CPU 特权态（Ring 0）的宿主机内核模块（nvidia.ko、nvidia-uvm.ko、nvidia-peermem.ko）与用户态驱动动态链接库（libcuda.so、libnvidia-ml.so）；
容器应用镜像内通常打包的是算法层依赖与 CUDA Runtime（libcudart.so，CUDA Toolkit），它绝不能也不可能在每个业务镜像中内嵌一个独立的内核驱动。

为了解决这一问题，容器平台确立了分工清晰的解耦生态（如图 4-1 与图 4-2 所示）：

宿主机专职管理物理设备与内核模块；
K8s Device Plugin 负责物理 GPU 资源发现、健康探测与配额向 Kubernetes API Server 的广告注册；
NVIDIA Container Toolkit 在容器启动时通过 OCI Hook 或现代 CDI（Container Device Interface）机制，动态向容器挂载设备字符节点与用户态驱动库；
建立严密的版本区间兼容性策略（Version Compatibility Matrix），规避宿主机驱动升级时导致的符号缺失与集群全域瘫痪。

2. 它如何工作

(1) NVIDIA 容器运行时分层架构与挂载机制

如图 4-1 所示，现代 GPU 容器技术栈由三个严格解耦的层级构成：

宿主机内核态（Host OS & Kernel Modules）：
物理机安装与系统内核严格匹配的英伟达驱动模块：nvidia.ko（硬件控制与寄存器访问）、nvidia-uvm.ko（统一虚拟内存支持）、nvidia-modeset.ko 与 nvidia-peermem.ko（RDMA 显存直通支持），同时常驻 nvidia-fabricmanager 负责 NVSwitch 路由初始化。
容器运行时中间件（NVIDIA Container Toolkit / CDI）：
遵循 OCI 容器标准。当 containerd 接收到启动 GPU 容器的指令时，触发 Toolkit 的 prestart hook。Toolkit 负责：
- 在容器的 Linux Cgroups 中配置设备白名单（允许访问 Major 195 的 NVIDIA 字符设备）；
- 在容器内部创建设备节点：/dev/nvidia0～/dev/nvidia7、/dev/nvidiactl、/dev/nvidia-uvm；
- 将宿主机的用户态驱动库（libcuda.so.1、libnvidia-ml.so.1）挂载进容器，并动态配置 ld.so.cache。
应用容器用户态（Application Container）：
开发者镜像内部携带应用代码、PyTorch 及通过 Wheel 或 Conda 安装的 CUDA Toolkit（libcudart.so）。容器启动后，libcudart.so 自动寻找并动态加载宿主机注入的 libcuda.so.1（CUDA Driver API），顺利打通用户态到硬件的完整调用链。

(2) Kubernetes GPU 设备生命周期与调度流水线

如图 4-2 所示，GPU 从物理硬件暴露到被 Pod 容器消费经历严密的五步生命周期：

flowchart LR
    Start["Device Plugin 启动"] --> Query["调用 NVML 查询节点可用物理 GPU 数量"]
    Query --> Report["通过 gRPC ListAndWatch 向 Kubelet 注册 gpu 资源池"]
    Report --> Schedule["K8s 调度器分配 Pod 到当前节点"]
    Schedule --> Allocate["Kubelet 调用 DevicePlugin.Allocate() 挑选具体 GPU ID"]
    Allocate --> Hook["容器运行时 prestart hook 注入设备节点并启动容器"]

图 4-2：Kubernetes GPU 设备发现、配额上报与容器挂载生命周期

插件启动与硬件探测：NVIDIA Device Plugin 作为 DaemonSet 运行在每个 GPU 节点，通过 NVML API 查询物理 GPU 数量并实时监控其温度与 ECC 错误状态；
资源配额上报（ListAndWatch）：Device Plugin 通过 Unix Domain Socket 向本地 Kubelet 发送 Register 请求，并通过 gRPC ListAndWatch 流实时向 Kubelet 上报健康 GPU 列表（资源标识为 nvidia.com/gpu）；
集群调度决策：K8s 调度器匹配 Pod YAML 中的 resources.requests: {nvidia.com/gpu: 8}，依据节点可用配额将 Pod 调度到该节点；
设备精确分配（Allocate）：Kubelet 调用 Device Plugin 的 Allocate() gRPC 接口，Device Plugin 挑选具体的物理设备 ID，并向 Kubelet 返回运行所需的环境变量（如 NVIDIA_VISIBLE_DEVICES=0,1）与挂载规范；
底层容器挂载启动：Kubelet 将该分配指令传递给底层 Container Runtime（containerd），触发 nvidia-container-toolkit 注入设备节点并启动容器。

3. 正确性条件与常见误区

误区一：容器内运行 nvidia-smi 成功即代表所有 AI 栈完全兼容
nvidia-smi 仅依赖基础的 NVML 库与控制设备 /dev/nvidiactl。在多机分布式训练中，若宿主机内核未加载 nvidia-uvm.ko，cudaMallocManaged 统一内存将报错；若未加载 nvidia-peermem.ko，跨节点 GPUDirect RDMA 将静默失效；若驱动版本与 CUDA Toolkit 存在 Major ABI 断层，编译链接时能通过但在算子运行时会报 CUDA error: driver/library version mismatch 或 symbol lookup error。
误区二：盲目进行在线驱动滚动升级（In-place Driver Upgrade）
NVIDIA 内核模块一旦被加载并与 GPU 硬件握手，如果宿主机上有任何进程（甚至包括存活的监控守护进程如 DCGM-Exporter）持有 /dev/nvidia* 文件描述符，直接尝试卸载内核驱动（rmmod nvidia）必然报 Device or resource busy。强行强制卸载或覆盖会导致内核 Kernel Panic 或驱动进入僵尸状态，摧毁该节点上所有运行中的业务。
误区三：忽略 NVIDIA Fabric Manager 的强版本绑定
在配备 NVSwitch 的大型服务器（如 DGX/HGX A100/H100）中，必须运行宿主机后台服务 nvidia-fabricmanager 来初始化 NVSwitch 路由拓扑。Fabric Manager 的版本号必须与底层 NVIDIA 驱动版本完全精确匹配（Bit-for-Bit Major.Minor.Patch 对齐）。若驱动升级而 Fabric Manager 未同步重启升级，NVLink 通信将彻底瘫痪。

4. 性能与工程取舍

镜像版本固定（Pinning）与基础设施升级债务的权衡：
业务算法团队倾向于在 Dockerfile 中锁定特定的旧版 CUDA 基础镜像以确保实验环境的绝对确定性；而平台运维团队为了支持新一代加速卡、修复底层漏洞与提升性能，必须持续推进宿主机驱动升级。借助 NVIDIA 驱动的前向兼容机制（Forward Compatibility Package），允许在较旧的驱动上运行较新的 CUDA Toolkit，但需要严格控制版本兼容区间，避免积累难以维护的技术债务。
节点排空（Cordon & Drain）与资源碎片化代价：
在生产集群中升级 GPU 驱动的唯一安全标准是金丝雀滚动排空（Canary Drain）：首先标记节点不可调度（kubectl cordon），随后优雅驱逐存量工作负载（kubectl drain），确认无任何 GPU 进程后再升级驱动并重启 Fabric Manager，验证健康后重新上线。这一过程会暂时减少集群的可用卡数，并可能引入局部的调度碎片，但能确保将升级故障的爆炸半径限制在单机范围。

具体演示

设某训练应用依赖的 NVIDIA 驱动主版本区间为 550.0 至 570.0（包含端点）：

节点 A 运行驱动版本 (555, 42)：满足 $550.0 \le 555.42 \le 570.0$ ，兼容检查通过，调度器可正常分配；
节点 B 运行驱动版本 (545, 23)：低于最低要求 $550.0$ ，兼容检查失败。调度器应直接在 Filter 预选阶段将其过滤，防止 Pod 启动后因内核驱动符号不兼容而崩溃；
某框架允许任意向上兼容（maximum=None），节点运行 (600, 0)：满足下界要求且无上界限制，通过校验。

请先独立复述“输入 → 状态变化 → 输出/指标”，再开始填空。

实践任务：唯一代码填空题

补齐多组件版本约束校验；版本用整数 tuple 比较。

只能修改 TODO/______ 位置，不得删除断言或放宽通过条件。

Code

def compatible(version, minimum, maximum=None):
    if not version or not minimum:
        raise ValueError("empty version")
    upper_ok = True if maximum is None else version <= maximum
    # TODO：同时满足下界与可选上界。
    return ______

assert compatible((555, 42), (550, 0), (570, 0))
assert not compatible((545, 23), (550, 0), (570, 0))
assert compatible((600, 0), (550, 0), None)

检查方法

运行本单元格，所有断言必须通过；再补一个边界输入并解释预期。

Q1

为什么 CUDA toolkit 在容器内，driver 通常仍必须在 host？

你的答案：

Q2

Device Plugin advertised 8 GPUs，但 Pod 内看不到设备，排查链路是什么？

你的答案：

Q3

GPU 驱动滚动升级为什么需要节点排空与回滚门槛？

你的答案：

评分规则

代码 4 分：正常输入 2 分、边界输入 1 分、解释 1 分；
Q1～Q3 各 2 分；
一票否决：混淆测量与推测、忽略租户/请求隔离、用平均值掩盖尾延迟、删除失败路径。

💡 点击展开参考答案与详细代码实现

参考答案（仅 answer 分支）

先独立完成。核对后请改变一个规模或故障条件重新推演。

Code

def compatible(version, minimum, maximum=None):
    if not version or not minimum:
        raise ValueError("empty version")
    upper_ok = True if maximum is None else version <= maximum
    return version >= minimum and upper_ok

assert compatible((555, 42), (550, 0), (570, 0))
assert not compatible((545, 23), (550, 0), (570, 0))
assert compatible((600, 0), (550, 0), None)

Q1 参考答案

在现代 Linux 容器与 GPU 硬件架构体系中，驱动与 Toolkit 的分离是由操作系统权限模型与内核共享本质决定的：

Linux 容器共享宿主机内核（Host Kernel Sharing）：容器并不是独立的虚拟机，它没有独立的操作系统内核。容器内的所有进程直接运行在宿主机的单一 Linux 内核之上；
GPU 驱动核心属于内核态特权模块（Kernel-Space Modules）：NVIDIA 驱动的核心部分（nvidia.ko、nvidia-uvm.ko、nvidia-peermem.ko）是 Linux 内核可加载模块（LKM），运行在 CPU Ring 0 特权级，直接负责物理 PCI 寄存器配置、硬件中断响应、显存物理页管理与 DMA 引擎控制。运行在用户空间（Ring 3）的容器绝不可能独立加载或运行操作系统内核模块；
用户态库（User-Space Libraries）与内核契约：CUDA Toolkit（包含编译器 nvcc、运行时 libcudart.so 及 cuBLAS/cuDNN 数学库）纯粹是用户态应用层代码，只需通过标准的系统调用与用户态驱动 API（libcuda.so.1）同底层内核驱动交互。因此，CUDA Toolkit 可以随业务镜像自由打包分发，而控制底层物理硬件的驱动必须由宿主机内核独占管理并按需透传。

Q2 参考答案

若 Device Plugin 已经向 Kubelet 上报并广告了 8 张 GPU，但 Pod 启动后内部无法看到设备，必须严格沿着以下自底向上的五级链路系统排查：

检查 Pod 资源声明规格（Pod Resource Spec）：检查 Pod YAML 中的 resources.requests/limits 是否显式声明了 nvidia.com/gpu: X。若未显式声明，Kubernetes 调度器将把该容器视为普通 CPU 任务，Kubelet 不会触发任何 GPU 分配流程；
检查 Kubelet 分配状态（Allocate gRPC Invocation）：查看宿主机 Kubelet 日志，确认在容器创建前，Kubelet 是否成功调用了 Device Plugin 的 Allocate 接口，并检查 Device Plugin 返回的物理设备 ID 列表是否合法；
检查底层容器运行时与 OCI Hook（Runtime Hook / CDI）：检查 containerd 的配置文件（/etc/containerd/config.toml），确认是否将 nvidia-container-runtime 配置为默认运行时，或者检查 Container Device Interface (CDI) 规范生成是否正确。若运行时缺少 NVIDIA Hook，容器将无法挂载任何字符设备；
检查 Linux Cgroups 设备白名单权限：检查 Pod 对应的 Cgroups 目录（devices.allow 或 cgroup v2 的 eBPF 设备过滤器），确认是否允许该容器的主进程读写 Major 195（NVIDIA 字符设备）与 Major 235（NVIDIA-UVM 字符设备）的设备节点；
检查应用容器内部环境变量：检查容器内是否被注入或覆写了 NVIDIA_VISIBLE_DEVICES="none" 或 NVIDIA_VISIBLE_DEVICES="void"。NVIDIA Container Toolkit 依赖此环境变量来决定向容器挂载哪些设备，若被误置为空，Hook 会跳过所有设备挂载。

Q3 参考答案

对 GPU 物理节点执行驱动滚动升级必须强制要求前置节点排空（Cordon & Drain）与设立严格的回滚断路门槛，这是由硬件操作与分布式系统的脆弱性决定的：

内核模块卸载的不可逆破坏性（In-flight Process Destruction）：升级 NVIDIA 驱动必须卸载正在运行的旧版内核模块（rmmod nvidia）。若宿主机上有任何存量进程（甚至包括后台监控进程如 DCGM-Exporter）持有 /dev/nvidia* 字符设备的文件句柄，卸载操作将直接报错；强行强制卸载会导致 GPU 硬件状态机死锁或宿主机直接 Kernel Panic。必须先执行 kubectl drain 彻底排空业务，保证零 GPU 句柄占用；
避免分布式训练发生雪崩（Mitigating Blast Radius）：大规模分布式训练任务（如 512 卡或 1024 卡训练）跨越数十乃至上百个节点。若在线直接升级某一台节点的驱动，会导致该节点上的 Rank 瞬间崩溃，进而通过 NCCL 的同步屏障（Barrier）引发全集群任务连锁中断退出；
回滚断路门槛（Automated Rollback Gates）：驱动与 Fabric Manager 升级后，必须在单台金丝雀节点上自动运行自检流水线（涵盖小规模 GEMM 压测、P2P 带宽测试与 ECC 坏块扫描）。一旦探测到硬件降频、NVLink 拓扑未对齐或吞吐下降超过预设阈值，自动化运维系统必须立即阻止升级扩散并触发秒级回滚，防止有缺陷的驱动导致整个集群算力池瘫痪。

参考资料

API 与平台能力会演进；部署前应按目标版本重新核对。

← 上一课
第 3 课：存储层级、数据集与 Checkp… 下一课 →
第 5 课：Gang Scheduling …

--- title: "第 4 课：容器、驱动、Device Plugin 与升级兼容性" jupyter: python3 --- ::: {.callout-note appearance="simple"} **参考答案版**：包含完整代码实现与问答题深度参考解析。建议先独立完成练习题后再展开核对。 ::: ## 本课目标与完成标准本课产出：实现组件版本区间的兼容性检查，并解释 GPU 设备从节点到容器的分配链。通过要求：唯一代码填空题通过给定检查；Q1～Q3 都给出因果链；能指出一个正确性边界和一个性能/运营取舍；总分至少 8/10。 ## 与既有六条主线的边界本课不教 Kubernetes 命令清单；重点是 host driver、container runtime、device plugin、CUDA user-space 和作业镜像之间的责任边界。前置：Linux/网络基础、runtime 补充线、train 分布式章节。本课只补 AI Infra 缺口，不重复已经完成的 kernel 或并行算法推导。 ## 核心心智模型 ### 1. 它是什么，解决什么问题在云原生 AI 算力平台中，平台工程师面临的核心挑战是：如何将物理宿主机上极其复杂的英伟达 GPU 硬件生态（包含底层内核模块、微码固件、Fabric Manager、专有驱动、NVML 监控库）安全、弹性且透明地交付给成千上万个运行在 Kubernetes Pod 容器中的深度学习应用（如 PyTorch、vLLM、Megatron-LM）？传统容器技术与 GPU 硬件直通之间存在本质上的架构分层矛盾（如图 4-1 所示）： ```{mermaid} flowchart TD subgraph HostOS["宿主机环境 (Host OS)"] Kernel["Linux 内核"] Driver["NVIDIA 驱动 (nvidia.ko)"] Toolkit["nvidia-container-toolkit"] end subgraph K8s["Kubernetes 集群调度"] Kubelet["Kubelet 节点守护进程"] DevPlugin["NVIDIA K8s Device Plugin"] end subgraph Container["应用容器 (Pod Container)"] CUDA["CUDA Runtime (libcudart)"] PyTorch["PyTorch / AI 训练推理框架"] end DevPlugin -->|向 Kubelet 上报 nvidia.com/gpu 资源| Kubelet Toolkit -->|挂载驱动字符设备 /dev/nvidia*| Container ``` 图 4-1：NVIDIA 容器运行时生态与 K8s Device Plugin 分层交互拓扑 - Linux 容器（如 Docker、containerd）本质上是基于 Linux 内核 Namespace（PID、Mount、Network）与 Cgroups 实现的轻量级进程隔离，**所有容器共享宿主机内核（Host Kernel）**； - GPU 是高度专用的硬件外设，其驱动分为运行在 CPU 特权态（Ring 0）的**宿主机内核模块（`nvidia.ko`、`nvidia-uvm.ko`、`nvidia-peermem.ko`）**与用户态驱动动态链接库（`libcuda.so`、`libnvidia-ml.so`）； - 容器应用镜像内通常打包的是算法层依赖与 CUDA Runtime（`libcudart.so`，CUDA Toolkit），它绝不能也不可能在每个业务镜像中内嵌一个独立的内核驱动。为了解决这一问题，容器平台确立了分工清晰的解耦生态（如图 4-1 与图 4-2 所示）： 1. 宿主机专职管理物理设备与内核模块； 2. **K8s Device Plugin** 负责物理 GPU 资源发现、健康探测与配额向 Kubernetes API Server 的广告注册； 3. **NVIDIA Container Toolkit** 在容器启动时通过 OCI Hook 或现代 CDI（Container Device Interface）机制，动态向容器挂载设备字符节点与用户态驱动库； 4. 建立严密的版本区间兼容性策略（Version Compatibility Matrix），规避宿主机驱动升级时导致的符号缺失与集群全域瘫痪。 ### 2. 它如何工作 #### (1) NVIDIA 容器运行时分层架构与挂载机制如图 4-1 所示，现代 GPU 容器技术栈由三个严格解耦的层级构成： 1. **宿主机内核态（Host OS & Kernel Modules）**：物理机安装与系统内核严格匹配的英伟达驱动模块：`nvidia.ko`（硬件控制与寄存器访问）、`nvidia-uvm.ko`（统一虚拟内存支持）、`nvidia-modeset.ko` 与 `nvidia-peermem.ko`（RDMA 显存直通支持），同时常驻 `nvidia-fabricmanager` 负责 NVSwitch 路由初始化。 2. **容器运行时中间件（NVIDIA Container Toolkit / CDI）**：遵循 OCI 容器标准。当 containerd 接收到启动 GPU 容器的指令时，触发 Toolkit 的 `prestart hook`。Toolkit 负责： - 在容器的 Linux Cgroups 中配置设备白名单（允许访问 Major 195 的 NVIDIA 字符设备）； - 在容器内部创建设备节点：`/dev/nvidia0`～`/dev/nvidia7`、`/dev/nvidiactl`、`/dev/nvidia-uvm`； - 将宿主机的用户态驱动库（`libcuda.so.1`、`libnvidia-ml.so.1`）挂载进容器，并动态配置 `ld.so.cache`。 3. **应用容器用户态（Application Container）**：开发者镜像内部携带应用代码、PyTorch 及通过 Wheel 或 Conda 安装的 CUDA Toolkit（`libcudart.so`）。容器启动后，`libcudart.so` 自动寻找并动态加载宿主机注入的 `libcuda.so.1`（CUDA Driver API），顺利打通用户态到硬件的完整调用链。 #### (2) Kubernetes GPU 设备生命周期与调度流水线如图 4-2 所示，GPU 从物理硬件暴露到被 Pod 容器消费经历严密的五步生命周期： ```{mermaid} flowchart LR Start["Device Plugin 启动"] --> Query["调用 NVML 查询节点可用物理 GPU 数量"] Query --> Report["通过 gRPC ListAndWatch 向 Kubelet 注册 gpu 资源池"] Report --> Schedule["K8s 调度器分配 Pod 到当前节点"] Schedule --> Allocate["Kubelet 调用 DevicePlugin.Allocate() 挑选具体 GPU ID"] Allocate --> Hook["容器运行时 prestart hook 注入设备节点并启动容器"] ``` 图 4-2：Kubernetes GPU 设备发现、配额上报与容器挂载生命周期 1. **插件启动与硬件探测**：NVIDIA Device Plugin 作为 DaemonSet 运行在每个 GPU 节点，通过 NVML API 查询物理 GPU 数量并实时监控其温度与 ECC 错误状态； 2. **资源配额上报（ListAndWatch）**：Device Plugin 通过 Unix Domain Socket 向本地 Kubelet 发送 `Register` 请求，并通过 gRPC `ListAndWatch` 流实时向 Kubelet 上报健康 GPU 列表（资源标识为 `nvidia.com/gpu`）； 3. **集群调度决策**：K8s 调度器匹配 Pod YAML 中的 `resources.requests: {nvidia.com/gpu: 8}`，依据节点可用配额将 Pod 调度到该节点； 4. **设备精确分配（Allocate）**：Kubelet 调用 Device Plugin 的 `Allocate()` gRPC 接口，Device Plugin 挑选具体的物理设备 ID，并向 Kubelet 返回运行所需的环境变量（如 `NVIDIA_VISIBLE_DEVICES=0,1`）与挂载规范； 5. **底层容器挂载启动**：Kubelet 将该分配指令传递给底层 Container Runtime（containerd），触发 `nvidia-container-toolkit` 注入设备节点并启动容器。 ### 3. 正确性条件与常见误区 - **误区一：容器内运行 `nvidia-smi` 成功即代表所有 AI 栈完全兼容** `nvidia-smi` 仅依赖基础的 NVML 库与控制设备 `/dev/nvidiactl`。在多机分布式训练中，若宿主机内核未加载 `nvidia-uvm.ko`，`cudaMallocManaged` 统一内存将报错；若未加载 `nvidia-peermem.ko`，跨节点 GPUDirect RDMA 将静默失效；若驱动版本与 CUDA Toolkit 存在 Major ABI 断层，编译链接时能通过但在算子运行时会报 `CUDA error: driver/library version mismatch` 或 `symbol lookup error`。 - **误区二：盲目进行在线驱动滚动升级（In-place Driver Upgrade）** NVIDIA 内核模块一旦被加载并与 GPU 硬件握手，如果宿主机上有任何进程（甚至包括存活的监控守护进程如 DCGM-Exporter）持有 `/dev/nvidia*` 文件描述符，直接尝试卸载内核驱动（`rmmod nvidia`）必然报 `Device or resource busy`。强行强制卸载或覆盖会导致内核 Kernel Panic 或驱动进入僵尸状态，摧毁该节点上所有运行中的业务。 - **误区三：忽略 NVIDIA Fabric Manager 的强版本绑定** 在配备 NVSwitch 的大型服务器（如 DGX/HGX A100/H100）中，必须运行宿主机后台服务 `nvidia-fabricmanager` 来初始化 NVSwitch 路由拓扑。**Fabric Manager 的版本号必须与底层 NVIDIA 驱动版本完全精确匹配（Bit-for-Bit Major.Minor.Patch 对齐）**。若驱动升级而 Fabric Manager 未同步重启升级，NVLink 通信将彻底瘫痪。 ### 4. 性能与工程取舍 - **镜像版本固定（Pinning）与基础设施升级债务的权衡**：业务算法团队倾向于在 Dockerfile 中锁定特定的旧版 CUDA 基础镜像以确保实验环境的绝对确定性；而平台运维团队为了支持新一代加速卡、修复底层漏洞与提升性能，必须持续推进宿主机驱动升级。借助 NVIDIA 驱动的前向兼容机制（Forward Compatibility Package），允许在较旧的驱动上运行较新的 CUDA Toolkit，但需要严格控制版本兼容区间，避免积累难以维护的技术债务。 - **节点排空（Cordon & Drain）与资源碎片化代价**：在生产集群中升级 GPU 驱动的唯一安全标准是金丝雀滚动排空（Canary Drain）：首先标记节点不可调度（`kubectl cordon`），随后优雅驱逐存量工作负载（`kubectl drain`），确认无任何 GPU 进程后再升级驱动并重启 Fabric Manager，验证健康后重新上线。这一过程会暂时减少集群的可用卡数，并可能引入局部的调度碎片，但能确保将升级故障的爆炸半径限制在单机范围。 ## 具体演示设某训练应用依赖的 NVIDIA 驱动主版本区间为 `550.0` 至 `570.0`（包含端点）： - 节点 A 运行驱动版本 `(555, 42)`：满足 $550.0 \le 555.42 \le 570.0$，兼容检查通过，调度器可正常分配； - 节点 B 运行驱动版本 `(545, 23)`：低于最低要求 $550.0$，兼容检查失败。调度器应直接在 Filter 预选阶段将其过滤，防止 Pod 启动后因内核驱动符号不兼容而崩溃； - 某框架允许任意向上兼容（`maximum=None`），节点运行 `(600, 0)`：满足下界要求且无上界限制，通过校验。请先独立复述“输入 → 状态变化 → 输出/指标”，再开始填空。 ## 实践任务：唯一代码填空题补齐多组件版本约束校验；版本用整数 tuple 比较。只能修改 `TODO`/`______` 位置，不得删除断言或放宽通过条件。 ```{python} #| course_role: exercise def compatible(version, minimum, maximum=None): if not version or not minimum: raise ValueError("empty version") upper_ok = True if maximum is None else version <= maximum # TODO：同时满足下界与可选上界。 return ______ assert compatible((555, 42), (550, 0), (570, 0)) assert not compatible((545, 23), (550, 0), (570, 0)) assert compatible((600, 0), (550, 0), None) ``` ### 检查方法运行本单元格，所有断言必须通过；再补一个边界输入并解释预期。 ### Q1 为什么 CUDA toolkit 在容器内，driver 通常仍必须在 host？ **你的答案：** ### Q2 Device Plugin advertised 8 GPUs，但 Pod 内看不到设备，排查链路是什么？ **你的答案：** ### Q3 GPU 驱动滚动升级为什么需要节点排空与回滚门槛？ **你的答案：** ## 评分规则 - 代码 4 分：正常输入 2 分、边界输入 1 分、解释 1 分； - Q1～Q3 各 2 分； - 一票否决：混淆测量与推测、忽略租户/请求隔离、用平均值掩盖尾延迟、删除失败路径。 ::: {.callout-tip collapse="true" title="💡 点击展开参考答案与详细代码实现" icon="false"} ## 参考答案（仅 answer 分支）先独立完成。核对后请改变一个规模或故障条件重新推演。 ```{python} #| course_role: solution def compatible(version, minimum, maximum=None): if not version or not minimum: raise ValueError("empty version") upper_ok = True if maximum is None else version <= maximum return version >= minimum and upper_ok assert compatible((555, 42), (550, 0), (570, 0)) assert not compatible((545, 23), (550, 0), (570, 0)) assert compatible((600, 0), (550, 0), None) ``` ### Q1 参考答案在现代 Linux 容器与 GPU 硬件架构体系中，驱动与 Toolkit 的分离是由操作系统权限模型与内核共享本质决定的： 1. **Linux 容器共享宿主机内核（Host Kernel Sharing）**：容器并不是独立的虚拟机，它没有独立的操作系统内核。容器内的所有进程直接运行在宿主机的单一 Linux 内核之上； 2. **GPU 驱动核心属于内核态特权模块（Kernel-Space Modules）**：NVIDIA 驱动的核心部分（`nvidia.ko`、`nvidia-uvm.ko`、`nvidia-peermem.ko`）是 Linux 内核可加载模块（LKM），运行在 CPU Ring 0 特权级，直接负责物理 PCI 寄存器配置、硬件中断响应、显存物理页管理与 DMA 引擎控制。运行在用户空间（Ring 3）的容器绝不可能独立加载或运行操作系统内核模块； 3. **用户态库（User-Space Libraries）与内核契约**：CUDA Toolkit（包含编译器 `nvcc`、运行时 `libcudart.so` 及 cuBLAS/cuDNN 数学库）纯粹是用户态应用层代码，只需通过标准的系统调用与用户态驱动 API（`libcuda.so.1`）同底层内核驱动交互。因此，CUDA Toolkit 可以随业务镜像自由打包分发，而控制底层物理硬件的驱动必须由宿主机内核独占管理并按需透传。 ### Q2 参考答案若 Device Plugin 已经向 Kubelet 上报并广告了 8 张 GPU，但 Pod 启动后内部无法看到设备，必须严格沿着以下**自底向上的五级链路**系统排查： 1. **检查 Pod 资源声明规格（Pod Resource Spec）**：检查 Pod YAML 中的 `resources.requests/limits` 是否显式声明了 `nvidia.com/gpu: X`。若未显式声明，Kubernetes 调度器将把该容器视为普通 CPU 任务，Kubelet 不会触发任何 GPU 分配流程； 2. **检查 Kubelet 分配状态（Allocate gRPC Invocation）**：查看宿主机 Kubelet 日志，确认在容器创建前，Kubelet 是否成功调用了 Device Plugin 的 `Allocate` 接口，并检查 Device Plugin 返回的物理设备 ID 列表是否合法； 3. **检查底层容器运行时与 OCI Hook（Runtime Hook / CDI）**：检查 containerd 的配置文件（`/etc/containerd/config.toml`），确认是否将 `nvidia-container-runtime` 配置为默认运行时，或者检查 Container Device Interface (CDI) 规范生成是否正确。若运行时缺少 NVIDIA Hook，容器将无法挂载任何字符设备； 4. **检查 Linux Cgroups 设备白名单权限**：检查 Pod 对应的 Cgroups 目录（`devices.allow` 或 cgroup v2 的 eBPF 设备过滤器），确认是否允许该容器的主进程读写 Major 195（NVIDIA 字符设备）与 Major 235（NVIDIA-UVM 字符设备）的设备节点； 5. **检查应用容器内部环境变量**：检查容器内是否被注入或覆写了 `NVIDIA_VISIBLE_DEVICES="none"` 或 `NVIDIA_VISIBLE_DEVICES="void"`。NVIDIA Container Toolkit 依赖此环境变量来决定向容器挂载哪些设备，若被误置为空，Hook 会跳过所有设备挂载。 ### Q3 参考答案对 GPU 物理节点执行驱动滚动升级必须强制要求**前置节点排空（Cordon & Drain）与设立严格的回滚断路门槛**，这是由硬件操作与分布式系统的脆弱性决定的： 1. **内核模块卸载的不可逆破坏性（In-flight Process Destruction）**：升级 NVIDIA 驱动必须卸载正在运行的旧版内核模块（`rmmod nvidia`）。若宿主机上有任何存量进程（甚至包括后台监控进程如 DCGM-Exporter）持有 `/dev/nvidia*` 字符设备的文件句柄，卸载操作将直接报错；强行强制卸载会导致 GPU 硬件状态机死锁或宿主机直接 Kernel Panic。必须先执行 `kubectl drain` 彻底排空业务，保证零 GPU 句柄占用； 2. **避免分布式训练发生雪崩（Mitigating Blast Radius）**：大规模分布式训练任务（如 512 卡或 1024 卡训练）跨越数十乃至上百个节点。若在线直接升级某一台节点的驱动，会导致该节点上的 Rank 瞬间崩溃，进而通过 NCCL 的同步屏障（Barrier）引发全集群任务连锁中断退出； 3. **回滚断路门槛（Automated Rollback Gates）**：驱动与 Fabric Manager 升级后，必须在单台金丝雀节点上自动运行自检流水线（涵盖小规模 GEMM 压测、P2P 带宽测试与 ECC 坏块扫描）。一旦探测到硬件降频、NVLink 拓扑未对齐或吞吐下降超过预设阈值，自动化运维系统必须立即阻止升级扩散并触发秒级回滚，防止有缺陷的驱动导致整个集群算力池瘫痪。 ## 参考资料 - [Kubernetes device plugins](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) - [NVIDIA GPU Operator](https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/) API 与平台能力会演进；部署前应按目标版本重新核对。 ::: ::: {.course-pagination} [**← 上一课** 第 3 课：存储层级、数据集与 Checkp...](lesson03.qmd){.pagination-link .pagination-prev} [**下一课 →** 第 5 课：Gang Scheduling ...](lesson05.qmd){.pagination-link .pagination-next} :::