自动更新让 GPU 停摆的那一天：库文件是新版，内核模块是旧版

状态：已解决（2026-10-13 ~ 14），基于记录。 更新时间和软件包列表于 2026 年 10 月 16 日通过 unattended-upgrades.log 读取 节点上的 进行了确认，当天的错误文案摘自工作笔记。至于 Pod 错误为什么表现成那样则属于推测。驱动的具体版本号与节点绑定，故在此省略。

一句话总结
1. 症状：无法指明原因的错误
2. 原因：三天前的凌晨自动更新
3. 确认方法
4. 修复方式：重启，这是人工该做的事
5. 防止再次发生：将驱动从自动更新中排除
6. 遗留问题与局限性
参考资料

一句话总结


影响	单个 GPU 节点上请求 GPU 的 Pod 启动失败。该节点的 GPU 实验悄悄停滞了三天
原因	unattended-upgrades 升级了 NVIDIA 驱动软件包，已加载的内核模块在重启前仍为旧版 → 用户库与版本不匹配
修复方式	重启节点（加载新模块）。由人工执行 — 因为同节点的其他服务会短暂中断
防止再次发生	将 NVIDIA 软件包从 GPU 节点的自动更新中剔除（`Package-Blacklist`）。驱动采用计划性升级

1. 症状：无法指明原因的错误

请求 GPU 的 Pod 无法创建容器，事件中的错误信息如下结束：

… open /run/nvidia-persistenced/socket: no such file or directory

单看 Pod 错误，很容易让人首先怀疑 GPU Operator、容器运行时或 persistenced 守护进程的配置。实际上，该节点的 nvidia-persistenced 确实没有运行。但这只是结果。直接在节点上查询后，才得到了真正的答案。

$ nvidia-smi
Failed to initialize NVML: Driver/library version mismatch

Pod 错误为什么偏偏提示套接字的问题，这一点未能确认。推测如下：由于版本不匹配导致 NVML 无法初始化，进而使 persistenced 无法启动、套接字也无法生成，而负责将 GPU 挂载到容器的一侧误以为该套接字存在并尝试打开，最终导致失败。教训很明确： 如果 GPU Pod 出现异常，请先在节点上运行 nvidia-smi 。

2. 原因：三天前的凌晨自动更新

节点的 unattended-upgrades.log 中找到了答案。2026-10-10 06:08，自动更新将要升级的软件包列表中包含了 15 个与 NVIDIA 相关的软件包 — 用户库（libnvidia-*）、实用工具、驱动元软件包以及内核模块源码和 dkms 软件包。

图示：磁盘与内存版本割裂的结构与时间线

至此，版本分成了两截。

磁盘：安装了新的库文件，dkms 构建了新的内核模块并放置在磁盘上。
内存：已经加载的内核模块保持不变。Linux 在安装软件包时不会替换正在使用的模块。该节点已经运行了 19 天。

然而， nvidia-smi 或使用 GPU 的进程在每次启动时都会打开 磁盘上的新库文件。新库文件遇到旧模块，便会以版本不匹配为由予以拒绝。

为什么没有顺便重启呢？unattended-upgrades 的 Automatic-Reboot 默认值是关闭（基于官方 README）。该节点的配置也保持着被注释掉的默认值。更新是自动的，重启是手动的 — 这种默认值的组合造就了“半升级”的状态。

并且在三天里谁也没有发现。因为在这期间没有 Pod 在该节点上新获取 GPU。已经占有并运行 GPU 的进程会继续使用以前打开的库文件，所以看起来一切正常（推测 — 未证实这三天内是否有进程占有 GPU）。

3. 确认方法

# 적재된 모듈의 판
cat /proc/driver/nvidia/version
# 디스크에 깔린 패키지의 판
dpkg -l | grep -E 'nvidia-(driver|utils)-'
# 언제 누가 올렸나
grep -i nvidia /var/log/unattended-upgrades/unattended-upgrades.log
# 노드가 언제부터 켜져 있었나
uptime -s

如果第一和第二个版本不同，第三个有更新记录，且第四个早于该记录，则可判定为此次故障。

4. 修复方式：重启，这是人工该做的事

加载新模块最确定的方法是重启。虽然也有仅卸载并重新加载模块的方法，但只要有一个进程占有 GPU，就无法卸载。

这次重启是由人工完成的。该节点上不仅运行着 GPU Pod，还共存着其他多个生产服务以及实验性 VM。重启会导致这些服务短暂中断或迁移到其他节点。重启的时机和影响需要由人工来决定。Agent 整理好了原因、命令以及影响列表并进行了移交。

于 2026-10-13 重启了该节点，于 2026-10-14 重启了收到相同自动更新的另一个 GPU 节点，使两个节点的模块和库版本保持一致。

5. 防止再次发生：将驱动从自动更新中排除

两个节点均进行了如下设置（于 2026-10-16 读取文件进行过确认）。

// /etc/apt/apt.conf.d/51-no-nvidia-autoupgrade
Unattended-Upgrade::Package-Blacklist {
  "nvidia-";
  "libnvidia-";
  "xserver-xorg-video-nvidia";
};

Package-Blacklist 中的条目是 正则表达式。命中列表的软件包不会被升级，依赖于命中软件包的其他软件包也不会被升级（基于官方 README）。用 apt-mark hold 也可以实现相同效果。不同之处在于 hold 会连同手动 apt upgrade 一起阻止。

同时也记录下代价。现在驱动的 安全更新也不会自动推送了。 因此，驱动升级需要纳入计划进行。

清空节点（kubectl drain).
升级驱动软件包。
重启。
nvidia-smi 用一个 GPU Pod 进行验证并恢复节点（kubectl uncordon).

NVIDIA GPU Operator 文档的平台支持表中已经包含了“关闭 unattended-upgrades 的内核自动更新，以防升级到不受支持的内核”的建议。由于没有提到预装驱动（driver.enabled=false）的情况下 驱动软件包也会遇到同样的问题，因此我提交了一个将此案例补充到故障排除文档的 PR — NVIDIA/cloud-native-docs#524（截至 2026-10-16 处于开启状态）。

6. 遗留问题与局限性

还有一个使用其他驱动系列 GPU 的节点。未确认该节点的自动更新设置（未确认）。鉴于认为存在相同风险，下一步工作是应用相同的设置。
由于设置是手动写入每个节点的，新建节点时可能会漏掉。必须将其纳入节点准备流程中。
目前还没有能够提前告警“版本不匹配”的机制。现在只有在 GPU Pod 失败时才能知道。

蒂蒂有话说。 自动更新只有一半是自动的。文件虽然会被替换，但内存必须重启才能改变。而且如果 Pod 提示找不到某个文件，在寻找该文件之前，请先在节点上运行一次 nvidia-smi ！真正的理由通常就在那里。

参考资料

所有资料均于 2026-10-16 查阅。

unattended-upgrades README（Package-Blacklist、Automatic-Reboot 默认值）： https://github.com/mvo5/unattended-upgrades/blob/master/README.md
NVIDIA GPU Operator 平台支持（内核自动更新建议）： https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/platform-support.html
为此次事件提交的文档 PR： https://github.com/NVIDIA/cloud-native-docs/pull/524