4. 迁移前评估：当前集群 Containerd 版本检测、节点操作系统兼容性、GPU/NPU 等特殊硬件驱动依赖

在正式执行 Containerd 运行时版本迁移之前，必须对集群现状进行系统性评估。跳过评估直接迁移可能导致节点不可用、Pod 调度失败或硬件加速能力丧失。本章聚焦三个核心评估维度：运行时版本基线、操作系统兼容性矩阵、GPU/NPU 等特殊硬件驱动依赖。

4.1 当前集群 Containerd 版本检测

版本检测需要覆盖集群中所有节点，包括 Control Plane 和 Worker 节点。推荐使用以下命令获取精确版本信息：

# 检测单个节点 containerd 版本
containerd --version

# 通过 crictl 获取运行时版本（需配置 endpoint）
crictl version

# 批量检测所有节点（使用 kubectl 和 node-shell 或直接 SSH）
kubectl get nodes -o wide
for node in $(kubectl get nodes -o name); do
  echo "=== $node ==="
  kubectl node-shell $node -- containerd --version 2>/dev/null || \
  ssh $node "containerd --version"
done

版本检测结果应记录到评估清单中，重点关注以下字段：

4.2 节点操作系统兼容性评估

不同 Linux 发行版对 containerd 版本的支持窗口存在差异。以下表格列出主流操作系统与 containerd 版本的兼容关系：

操作系统评估还需检查以下关键依赖：

• glibc 版本：containerd 2.0+ 要求 glibc ≥ 2.28，CentOS 7 默认 2.17 不满足。
• systemd 版本：推荐 systemd ≥ 245 以支持 cgroup v2。
• 内核参数：检查 net.ipv4.ip_forward、overlay 模块、br_netfilter 是否启用。
• cgroup 驱动：确认当前使用 cgroupfs 还是 systemd 驱动，迁移后需保持一致。

4.3 GPU/NPU 等特殊硬件驱动依赖

运行 AI/ML 工作负载的集群通常依赖 GPU（NVIDIA、AMD）或 NPU（华为昇腾、寒武纪）等加速硬件。Containerd 版本迁移可能影响设备插件、运行时钩子及驱动加载机制。以下 SVG 展示了 GPU 工作节点在 containerd 迁移前后的组件依赖关系：

4.4 特殊硬件驱动依赖检查清单

针对 GPU/NPU 节点，迁移前必须逐项确认以下依赖状态：

4.5 评估输出与风险标记

完成上述评估后，应生成一份结构化的评估报告，包含以下内容：

• 版本基线表：每个节点的 containerd、runc、cni-plugins 版本。
• 操作系统兼容性矩阵：标记不兼容节点（如 CentOS 7 需升级或替换）。
• 硬件驱动依赖清单：GPU/NPU 节点的驱动版本、工具链版本、设备插件版本。
• 风险等级标记：高风险（驱动不兼容、操作系统过旧）、中风险（工具链版本需同步升级）、低风险（仅版本号差异）。

评估报告将作为后续迁移策略制定和 Helm Chart 回滚适配的核心输入。只有所有节点通过评估，才能进入下一阶段的迁移执行。