gpu-node-lifecycle

GPU 节点生命周期运维：加入、下线、重启、驱动升级与重新调度的检查清单。

现象

新节点加入集群后长期 NotReady，或节点已经 Ready 但 nvidia.com/gpu 容量为零，GPU Pod 一直 Pending；device plugin 或 GPU Operator 组件反复重启；节点重启后驱动没有加载、MIG 配置丢失、Fabric Manager 未启动，训练任务全部失败。维护时执行 drain 却卡住不动，或者 Pod 被驱逐后没有回到其他节点。

驱动升级最容易出事：容器内 nvidia-smi 与宿主机不一致，旧任务出现 CUDA 错误或 Xid，新 Pod 无法分配 GPU；节点看似恢复，调度器却把任务放上去，随后再次失败。cordon 后仍被误调度、健康检查未完成就 uncordon，也会反复失败。

先确认节点处于哪个阶段：加入、下线、重启、升级、MIG 变更还是重新加入。不同阶段的检查项和回滚方式不同。

快速判断

先看节点和 GPU 资源的基本状态：

kubectl get nodes -o wide
kubectl describe node <node>
kubectl get node <node> -o jsonpath='{.status.conditions}'
kubectl get node <node> -o jsonpath='{.status.allocatable}'
kubectl get pods -A -o wide --field-selector spec.nodeName=<node>

再上节点检查驱动、设备、MIG 和服务：

nvidia-smi
nvidia-smi -L
nvidia-smi -q | grep -i -A5 -E 'mig|fabric'
ls -l /dev/nvidia*
systemctl status nvidia-fabricmanager
journalctl -u kubelet --since '30 min ago'
journalctl -k --since '30 min ago' | grep -i -E 'nvrm|xid|nvidia'

最后确认 device plugin、GPU Operator 和测试 Pod 能否真正拿到 GPU。宿主机 nvidia-smi 正常，不代表调度器能看到资源，也不代表容器内可用。

回答四个问题：

1. 节点注册了吗：kubelet、运行时和 CNI 是否正常，节点条件是否只剩 GPU 相关异常？
2. GPU 被调度器看见了吗：allocatable 里是否有 GPU 资源，插件是否 Ready？
3. 工作负载为什么没走：是容量不足，还是污点、亲和性、PDB 或配额阻止了调度？
4. 变更范围多大：只影响一个节点还是整个节点池？是否已备份配置并准备回滚？

常见原因

节点加入与注册

新节点的 kubelet、容器运行时、CNI、证书和时间同步任一异常，都会让节点无法加入或反复 NotReady。GPU 节点还需要正确的内核头文件、驱动、容器工具链和运行时配置；Secure Boot 下驱动签名不通过，内核模块无法加载。缺少 GPU 标签或节点池配置，调度器就不会把它当作 GPU 节点。

驱动、容器工具链与 Operator

宿主机驱动、CUDA 兼容层、容器 toolkit、device plugin 和 GPU Operator 需要成套匹配。只升级一项，可能出现宿主机能看到 GPU、容器内看不到，或插件上报资源与真实设备不符。升级后未重启或未重建内核模块，新驱动只生效一半；节点混跑不同版本时，问题只出现在部分节点。

device plugin 与 MIG

device plugin 负责把 GPU 和 MIG 设备上报为可调度资源。插件未运行、不识别当前 MIG 模式、资源名与工作负载请求不一致，都会让容量显示为零或少于预期。MIG 模式变更通常要停止 GPU 进程并重置设备，运行中的任务会中断；重启后未重新应用配置，切分和 profile 会丢失。MIG 与整卡混用、profile 名写错，也会让 Pod 无法分配。

下线、cordon 与 drain

cordon 只标记不可调度，不驱逐已有 Pod；drain 才会驱逐。PDB、DaemonSet、本地存储或 EmptyDir、卡住的 finalizer 都会让 drain 阻塞。强制删除可能丢失本地数据，让训练任务在没有 checkpoint 时退出。GPU 任务通常不支持优雅迁移，下线前必须确认断点和重新调度策略。

重启与启动顺序

节点重启后，内核模块、nvidia-persistenced、Fabric Manager、device plugin 和 kubelet 的启动顺序会影响 GPU 可用性。带 NVSwitch 的机器若 Fabric Manager 未启动或版本不匹配，NVLink 初始化和多卡训练都会异常。MIG 配置、GPU 复位状态、ECC 和 Xid 也要重新检查；nvidia-smi 能运行不等于节点健康。

调度与重新调度

GPU 资源名写错、节点选择器或亲和性排除了新节点、维护污点未移除、PDB 阻止驱逐、优先级和抢占配置不当，都会让 Pod 无法回到集群。自动扩缩容可能把任务放到尚未完成 GPU 初始化的节点；descheduler 也可能在维护期间搬动 Pod。容量不足时，drain 后的 Pod 会长期 Pending。

硬件与节点健康

Xid、ECC、NVLink 错误、温度或功耗异常、GPU 掉卡，都会让节点在重启后仍不适合训练。没有健康检查和自动 cordon 时，调度器会继续把任务放到问题节点，形成反复失败。驱动升级只是触发因素，根因可能在硬件或散热。

排查步骤

第一步：确认生命周期阶段

记录节点是刚加入、准备下线、刚重启、刚升级还是刚改过 MIG；查看变更记录、维护窗口和节点事件。阶段不明时不要同时改驱动、污点和插件配置，否则无法判断哪个变量起作用。

第二步：检查节点与 kubelet

kubectl describe node <node>
systemctl status kubelet containerd
journalctl -u kubelet --since '30 min ago'

关注节点条件、磁盘/内存/PID 压力和网络状态。节点 Ready 但 GPU 容量为零，问题通常在驱动或插件；NotReady 则先修 kubelet、运行时和 CNI，不要急着动 GPU。

第三步：检查 GPU 软件栈

确认驱动、设备节点和容器运行时配置，再查 device plugin 与 GPU Operator 日志。用测试 Pod 请求一张 GPU，验证从调度到容器内可见的链路。宿主机 nvidia-smi 正常但测试 Pod 失败，重点查运行时、toolkit、设备挂载和资源上报。

第四步：制定驱动升级方案

升级前查兼容矩阵，确认驱动、容器 toolkit、Operator、框架和内核模块匹配。选维护窗口，先 cordon 并 drain，确认没有任务占用 GPU；在测试或金丝雀节点验证 nvidia-smi、dcgmi diag、nccl-tests 和真实任务，再推广到整个节点池。保留旧驱动包、节点镜像和回滚步骤，禁止全池同时升级。

第五步：执行 cordon 与 drain

kubectl cordon <node>
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data

--delete-emptydir-data 会删除本地临时数据，使用前确认任务已有 checkpoint、日志已采集。先检查 PDB、DaemonSet、本地存储和 finalizer，确认 Pod 能迁移或有重跑计划。--force 只用于测试环境或确认数据可丢弃时；生产优先解决阻塞原因，而不是强删。

第六步：重启与启动后检查

重启前完成 drain 和维护标记。启动后依次检查内核模块、驱动、设备节点、Fabric Manager、MIG、device plugin、GPU 容量和节点条件，再跑硬件自检与通信测试，确认没有新的 Xid、ECC 增长或 NVLink 错误。任何一项失败都不要 uncordon。

第七步：处理 MIG 变更

MIG 模式切换会中断设备上的进程，属于破坏性操作。先在测试环境确认 profile、资源名和工作负载请求一致，再在维护窗口执行；变更后重启相关服务，核对 allocatable 中的 MIG 资源与 profile，并用测试 Pod 验证隔离和分配。准备恢复原模式的回滚步骤。

第八步：验证调度与重新调度

检查节点标签、污点、亲和性、资源名和配额，确认维护污点已移除、容量已上报。提交与生产同规格的测试 Pod，观察能否调度并成功运行。长任务要确认 checkpoint、重试和优先级策略有效，避免 drain 后长期 Pending 或反复失败。

第九步：健康门禁后再上线

uncordon 前完成：GPU 全部识别、容器内外驱动一致、MIG 符合预期、Fabric 正常、dcgmi diag 通过、nccl-tests 达到基线、没有新的 Xid 或 ECC 增长。把结果记入维护单，再移除污点并 uncordon。仅“节点 Ready”不构成上线依据。

修复与验证

按问题类型处理：

• 节点无法加入：修复 kubelet、运行时、CNI、证书和磁盘，确认节点条件恢复正常后再打 GPU 标签。
• GPU 容量为零：修复驱动与内核模块，重启 device plugin 或 Operator 组件，核对资源名和 MIG 配置，用测试 Pod 验证。
• 驱动升级失败：回滚到旧驱动或旧节点镜像，隔离问题节点，重新走金丝雀流程；不要在同一节点池混跑不兼容版本。
• drain 阻塞：检查 PDB、DaemonSet、本地存储和 finalizer，先保存 checkpoint 和日志，再决定迁移或重跑；强制删除仅限测试环境。
• MIG 异常：恢复原 MIG 模式或重新应用配置，重启相关服务，核对 profile 与 allocatable，再验证工作负载。
• 调度失败：修正标签、污点、亲和性、资源名和配额，确认节点容量上报后再放开调度。
• 硬件异常：按 Xid、ECC 和压测结果下线复检，修复或更换后再走健康门禁。

验证至少覆盖：

1. 节点 Ready，GPU allocatable 数量与物理设备或 MIG profile 一致。
2. 测试 Pod 能成功请求 GPU，容器内 nvidia-smi 正常。
3. dcgmi diag 和 nccl-tests 通过，结果与节点基线一致。
4. 真实训练任务能启动、保存 checkpoint 并在其他节点恢复。
5. 观察窗口内没有新的 Xid、ECC 增长、插件重启或节点条件反复。

drain、强制删除、驱动升级、节点重启和 MIG 重配都可能中断训练或丢失本地数据。操作前确认测试环境验证过、备份可用、维护窗口已批准，并准备明确的回滚路径。

预防

• 节点镜像和驱动版本固定，升级走金丝雀节点和分批次发布，禁止整个节点池同时变更。
• 把 GPU 节点维护固化为流程：cordon、drain、检查、升级、重启、健康门禁、uncordon。
• MIG 配置、device plugin 配置和节点标签纳入版本管理，节点重建后自动恢复。
• 维护期间给节点打污点，确认调度器不会把新 Pod 放到未完成初始化的节点。
• 长任务必须具备 checkpoint、重试和优先级策略，下线前自动触发保存。
• 监控节点条件、GPU 容量、插件状态、驱动版本漂移、Xid 和 ECC，异常时自动 cordon。
• 保留容量缓冲，避免 drain 后负载无处可去；PDB 和配额要按真实故障演练。
• 定期做节点重启、驱动回滚和 MIG 恢复演练，验证文档与自动化脚本确实可用。

相关命令

• nvidia-smi — 查看 GPU、驱动、MIG 与进程状态。
• nvidia-mig — MIG 切分、profile 与生命周期注意事项。
• nvidia-container-toolkit — 容器 GPU 设备注入与运行时配置。
• nvidia-fabricmanager — NVSwitch 路由服务与启动顺序。
• gpu-xid — 升级或重启后出现 Xid 的定位。
• dcgm — 节点健康检查与诊断。
• gpu-burn — 受控压测与散热验证。
• GPU Operator — 节点 GPU 软件栈的统一管理。
• nvidia-device-plugin — GPU 资源上报与调度。
• taints-tolerations — 维护污点与工作负载容忍。
• kured — 节点重启的编排与安全窗口。
• descheduler — 重新调度策略与维护期风险。

参考链接

• Kubernetes 安全 drain 节点
• NVIDIA GPU Operator 文档

读完自测

合上页面，先回答，再展开对照。

1. 节点 Ready 但 nvidia.com/gpu 容量为零，应该先查哪一层？
2. cordon 和 drain 有什么区别，为什么下线 GPU 节点前要先确认 checkpoint？
3. 驱动升级后节点能识别 GPU，为什么还不能直接 uncordon？