containerd运行时版本迁移与Helm回滚策略适配 - 第2节
2.1 containerd 架构全景：从 Docker 到 CRI 的中间层
在 Kubernetes 生态中，containerd 并非直接与 Docker 竞争，而是作为容器运行时标准化的产物。理解 containerd 的架构，首先需要厘清它与 Docker 的关系：Docker 是一个完整的容器平台（CLI + API + 编排 + 运行时），而 containerd 是 Docker 剥离出的核心运行时组件，现已成为 CNCF 毕业项目。
关键认知： Docker 18.09+ 版本底层已默认使用 containerd 作为运行时引擎。因此，从 Docker 迁移到 containerd 并非“替换”，而是“解耦”——去掉 Docker 的 CLI 和守护进程，直接通过 CRI（Container Runtime Interface）与 kubelet 交互。
2.1.1 架构分层对比
| 层级 | Docker 栈 | containerd 栈 | 说明 |
|---|---|---|---|
| 用户接口 | docker CLI / API | ctr / crictl / nerdctl | containerd 提供更轻量的 CLI |
| 编排层 | Docker Compose / Swarm | Kubernetes CRI | containerd 原生对接 kubelet |
| 守护进程 | dockerd（含 containerd 嵌入） | containerd 独立守护进程 | 无 dockerd 中间层 |
| 容器管理 | containerd（内部） | containerd + shim | 核心组件一致 |
| OCI 运行时 | runc（默认） | runc / kata / gVisor | 可插拔运行时 |
迁移启示： 当 Helm 部署的 Pod 因运行时版本不兼容而 CrashLoopBackOff 时，回滚策略往往需要同时考虑 containerd 版本与 shim 的兼容性，而非仅回滚应用 Chart。
2.2 containerd 核心组件深度解析
containerd 的架构设计遵循“单一职责 + 插件化”原则，核心组件包括 shim、snapshotter、metadata 存储 三大模块。下面通过架构图展示它们之间的协作关系。
2.2.1 containerd-shim：容器的“守护代理”
shim 是每个容器独立的轻量级进程，位于 containerd 守护进程与 OCI 运行时（如 runc）之间。它的核心职责包括：
- 生命周期隔离： 当 containerd 重启或升级时，shim 保持容器进程存活，避免容器被连带杀死。
- 标准输入/输出/错误（stdio）管理： 将容器的 stdout/stderr 转发回 containerd，支持日志收集。
- 退出码捕获： 容器退出后，shim 负责收集退出状态并通知 containerd。
- 运行时抽象： 通过 OCI 运行时规范，支持 runc、kata-containers、gVisor 等不同实现。
版本迁移风险点： 不同 containerd 版本对 shim v1/v2 的支持不同。从 containerd 1.5 迁移到 1.6+ 时，shim v1 被标记为废弃，若 Helm Chart 中显式指定了 shim 版本，回滚时必须同步检查 shim 兼容性，否则容器启动会失败。
2.2.2 Snapshotter：镜像层管理引擎
Snapshotter 负责管理容器镜像的层（layer）挂载与快照。它决定了容器文件系统的构建方式，直接影响 Pod 启动速度和磁盘利用率。
| Snapshotter 类型 | 驱动方式 | 适用场景 | 版本支持 |
|---|---|---|---|
| overlayfs | 内核 OverlayFS | 默认推荐，性能最佳 | containerd 1.0+ |
| devmapper | Device Mapper 快照 | 需要精简配置、快照隔离 | containerd 1.3+ |
| native | 目录拷贝 | 兼容性兜底 | 所有版本 |
| aufs | Another UnionFS | 老旧内核兼容 | 已废弃（1.5+ 移除） |
迁移检查项： 在 containerd 版本迁移前，务必确认目标版本是否仍支持当前使用的 snapshotter 类型。例如，从 containerd 1.4 迁移到 1.7，若使用 aufs 则需先切换为 overlayfs，否则回滚时镜像层无法挂载。
2.2.3 Metadata 存储：容器状态的“数据库”
containerd 使用 BoltDB（嵌入式键值数据库）作为元数据持久化存储，同时维护内存索引以加速查询。存储的内容包括：
- 容器元数据： ID、名称、标签、注解、创建时间。
- 镜像元数据： 镜像名称、摘要、层列表、配置。
- 任务状态： 运行中、已暂停、已退出等。
- 快照引用： 每个容器层与 snapshotter 快照的映射关系。
版本迁移影响： BoltDB 的 schema 在不同 containerd 版本间可能发生变化。直接降级 containerd 版本可能导致 metadata 无法解析，因此回滚策略中必须包含 metadata 清理或备份恢复 步骤。
2.3 containerd 与 Docker 的关系：从“包含”到“替代”
为了更直观地理解两者关系，下面展示 Docker 与 containerd 在 Kubernetes 环境下的架构对比。
2.3.1 关键差异总结
| 维度 | Docker 栈 | containerd 栈 | 对 Helm 回滚的影响 |
|---|---|---|---|
| 调用链路 | kubelet → dockershim → dockerd → containerd → shim → runc | kubelet → containerd → shim → runc | containerd 栈故障点更少，回滚时排查链路更短 |
| 守护进程 | dockerd 作为额外中间层 | 无 dockerd | 回滚时无需考虑 dockerd 版本兼容性 |
| 镜像管理 | dockerd 管理镜像拉取/推送 | containerd 直接管理 | 回滚后镜像缓存可能不匹配，需清理 |
| 日志收集 | docker logs → json-file 驱动 | kubelet 直接读取 shim 的 stdout | 回滚后日志路径可能变化，需适配 |
课程核心观点： 在 Helm 回滚场景中，如果集群从 Docker 迁移到 containerd，回滚策略不能仅回滚应用 Chart，还必须检查 containerd 版本与 shim 的兼容性、snapshotter 配置是否匹配、metadata schema 是否支持降级。否则，即使 Helm Release 回滚成功，Pod 也可能因运行时错误而无法启动。
2.4 本章小结
- containerd 是 Docker 的核心运行时剥离产物，在 Kubernetes 中通过 CRI 直接与 kubelet 交互，去掉了 dockerd 中间层。
- 三大核心组件： shim（容器代理）、snapshotter（镜像层管理）、metadata（状态持久化），每个组件在版本迁移时都有独立的兼容性约束。
- 版本迁移风险： shim v1→v2 变更、snapshotter 类型废弃、BoltDB schema 不兼容，是 Helm 回滚策略中必须覆盖的检查点。
- 架构对比： containerd 栈比 Docker 栈更精简，但回滚时仍需逐层验证组件版本，不能仅依赖 Helm 的 Release 回滚机制。