1.1 Containerd 概述

Containerd 是一个工业级标准的容器运行时，负责容器的生命周期管理、镜像传输与存储、网络与存储挂载等核心操作。它从 Docker 项目中剥离并捐赠给 CNCF，成为 Kubernetes 默认的容器运行时接口（CRI）实现之一。理解 Containerd 的起源、架构及其在 Kubernetes 中的角色，是进行版本迁移与流水线适配的基础。

1.1.1 起源与演进

Containerd 的诞生与 Docker 的架构拆分密切相关。2014 年 Docker 推出 1.0 版本后，其单体架构逐渐暴露出可维护性与性能瓶颈。2016 年，Docker 将核心容器管理逻辑抽取为独立的守护进程，即 Containerd，随后将其捐赠给 CNCF 基金会。这一拆分使得 Kubernetes 能够直接对接 Containerd，而不必依赖完整的 Docker Engine。

1.1.2 架构设计

Containerd 采用模块化、插件化的分层架构，核心组件包括 gRPC API 层、核心服务层、存储层和底层运行时接口。下图展示了 Containerd 的内部组件及其与上层编排系统、底层操作系统的关系。

架构中的关键设计要点：

• gRPC API 层：对外暴露 CRI（Container Runtime Interface）接口，兼容 Kubernetes 调用；同时提供命名空间隔离，支持多租户场景。
• 核心服务层：包含容器生命周期管理（创建、启动、停止、删除）、镜像拉取与缓存、网络命名空间与存储卷挂载、事件流与 Prometheus 指标。
• 存储层：通过快照器（Snapshotter）管理容器层文件系统，支持 overlayfs、devmapper、zfs 等后端；镜像仓库模块负责与 registry 交互。
• Shim 层：每个容器对应一个独立的 Shim 进程，Containerd 重启不影响运行中的容器，这是实现零停机升级的关键机制。

1.1.3 与 Docker 的关系

Containerd 与 Docker 并非竞争关系，而是上下游依赖关系。Docker Engine 在 1.11 版本之后内部调用 Containerd 来管理容器，而 Docker CLI 和 Docker Compose 等上层工具仍然保留。下表对比了两者的核心差异：

1.1.4 在 Kubernetes 中的角色

在 Kubernetes 架构中，Containerd 作为 CRI 实现，位于 kubelet 与底层操作系统之间。kubelet 通过 gRPC 调用 Containerd 的 CRI 接口，完成 Pod 沙箱创建、容器启动、镜像拉取、资源统计等操作。下图展示了 Containerd 在 Kubernetes 节点中的位置与数据流。

Containerd 在 Kubernetes 中的核心职责包括：

1. Pod 沙箱管理：通过 CRI 的 RunPodSandbox / StopPodSandbox 接口，为 Pod 创建独立的网络与 PID 命名空间。
2. 容器生命周期：CreateContainer / StartContainer / StopContainer / RemoveContainer，对应容器的完整生命周期。
3. 镜像管理：PullImage / ListImages / RemoveImage，支持镜像层缓存与垃圾回收。
4. 资源统计：ContainerStats / ListContainerStats，提供 CPU、内存、磁盘 I/O 等指标，供 kubelet 和 HPA 使用。
5. 容器日志：通过 CRI 的 ReopenContainerLog 接口，配合 kubelet 日志轮转策略。

1.1.5 版本迁移与流水线适配的切入点

基于上述架构理解，Containerd 版本迁移与发布流水线适配主要涉及以下四个层面：