containerd：容器运行时

为什么需要 containerd：从 Docker 到轻量级 CRI 运行时

在 Kubernetes 早期，节点上的容器管理链路很长：kubelet → dockerd → containerd → runc。dockerd 在其中只充当「转发层」，真正的容器创建和镜像解包工作已经由 containerd 完成，多一层守护进程意味着更多内存开销、更多故障点和更长的调用路径。2022 年 Kubernetes 1.24 正式移除 dockershim，kubelet 不再内置对 Docker 的适配，containerd 凭借 CRI 原生支持成为官方推荐的主流运行时。

containerd 解决的核心问题是「把容器运行这件事做纯粹且可插拔」：它对外提供稳定的 gRPC API 和 CRI 插件，对内通过 containerd-shim 管理每个容器的生命周期，使容器进程与守护进程解耦——即使 containerd 重启，容器也不会随之退出。同时它的快照器（Snapshotter）抽象让镜像层管理具备可扩展性，可以对接 overlayfs、stargz 加速镜像、Nydus 等不同存储方案。

与 CRI-O 相比，containerd 的优势在于生态更通用：它脱离 Kubernetes 也能以裸运行时方式使用（ctr/nerdctl），社区贡献者更多、更新节奏更活跃。与 Docker Engine 相比，它少了构建和 Compose 等上层能力，换来的是更小的二进制体积、更少的系统占用和更稳定的 CRI 兼容性——这也正是它在生产 K8s 集群中胜出的原因。

安装与环境配置：3 步就绪

安装 containerd 有 apt/yum 系统源和 GitHub Releases 二进制包两种主流方式。生产环境建议直接使用发行版官方源安装，便于通过系统包管理器做安全更新；需要尝鲜新特性时再选择二进制 tarball。

步骤一：安装

步骤二：生成并调整配置

步骤三：启动并验证

验证时注意 ctr plugins ls 应能看到 io.containerd.grpc.v1.cri 和 io.containerd.snapshotter.v1.overlayfs 处于 ok 状态。若 CRI 插件未加载，后续 Kubernetes 节点将无法注册，需检查 /etc/containerd/config.toml 中 disabled_plugins 是否误注释了 CRI 插件。

# Ubuntu/Debian 使用系统源安装sudo apt-get updatesudo apt-get install -y containerd # 或下载官方二进制 tarball（以 v2.0.x 为例）wget https://github.com/containerd/containerd/releases/download/v2.0.0/containerd-2.0.0-linux-amd64.tar.gzsudo tar Cxzvf /usr/local containerd-2.0.0-linux-amd64.tar.gz

# 生成默认配置sudo mkdir -p /etc/containerdcontainerd config default | sudo tee /etc/containerd/config.toml # 将 SystemdCgroup 设为 true（Kubernetes 推荐，保持与 kubelet 一致）sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml # 若需使用私有镜像仓库，在 config.toml 的 [plugins.'io.containerd.grpc.v1.cri'.registry] 段# 配置 config_path = "/etc/containerd/certs.d"

sudo systemctl enable --now containerdsudo systemctl status containerd --no-pagersudo ctr version        # 输出 Client/Server 版本即成功sudo ctr plugins ls     # 查看 snapshotter 与 CRI 插件加载情况

快速上手：10 分钟跑通第一个容器

containerd 自带 ctr 调试工具，适合快速验证安装是否正常。ctr 的用法与 docker 相似但不完全兼容：它操作的是 containerd API 而不是 Docker API，且默认工作在 default 命名空间。若节点已被 Kubernetes 占用，容器对象位于 k8s.io 命名空间，ctr 默认看不到，排查时务必加 -n 参数。

跑通后你会注意到 ctr 不支持 -p 端口映射、-v 数据卷这类「便利功能」——这正是它的定位：面向运行时调试而不是终端用户。日常在开发机上模拟 Docker 体验，建议安装 nerdctl，它能以兼容 docker run/build/compose 的方式操作同一个 containerd 实例，直接在宿主机验证生产环境同款镜像。

# 拉取 Redis 镜像（显式指定 docker.io 前缀）sudo ctr image pull docker.io/library/redis:7 # 查看本地镜像sudo ctr images ls # 运行一个临时容器：--rm 表示退出即删除sudo ctr run --rm docker.io/library/redis:7 redis-test redis-server --port 6380 # 另开终端进入同一容器内的交互 shellsudo ctr tasks exec --exec-id shell redis-test /bin/sh # 查看 Kubernetes 使用的镜像（k8s.io 命名空间）sudo ctr -n k8s.io images ls

核心能力详解：4 大支柱

支柱一：OCI 合规与镜像分发。 containerd 严格遵循 OCI（Open Container Initiative，开放容器倡议组织制定的容器镜像与运行时规范）标准，能拉取 Docker Hub、Harbor、GHCR 等任意符合 OCI 规范的镜像仓库。它实现了内容寻址存储（Content-Addressable Storage，镜像内容按哈希值存储与寻址），支持并发层下载、层去重与垃圾回收。配置 registry.mirrors 可将默认仓库指向内网加速器或私有仓库，certs.d 目录支持按域名配置 TLS 证书与认证信息，这是生产环境访问私有仓库的标准方式。

支柱二：快照器（Snapshotter）存储抽象。 快照器是 containerd 的存储引擎插件，负责管理镜像层与容器可写层的挂载关系。默认使用 overlayfs 实现层叠文件系统，同一宿主机上多个容器共享只读镜像层，显著节省磁盘空间。社区已出现 stargz、Nydus、EStargz 等加速型快照器，支持按需拉取（按需加载镜像数据块），适合大规模集群分发冷门镜像的场景。更换快照器只需修改 config.toml 的 snapshotter 字段并重启守护进程，业务层无感知。

支柱三：CRI 插件与 Kubernetes 集成。 CRI 是 kubelet 与容器运行时之间的标准接口。containerd 内置 io.containerd.grpc.v1.cri 插件，将 kubelet 的 PodSandbox（Pod 沙箱，K8s 为每个 Pod 创建的隔离环境）、容器创建、镜像拉取等请求翻译为内部 API 调用。通过 crictl 工具可以以 CRI 视角查看节点上的 Pod 与容器状态，定位 kubelet 与运行时之间的通信问题。CRI 插件还负责配置 Pod 级网络命名空间和挂载卷，并与 pause 镜像配合维持 Pod 生命周期。

支柱四：Namespace 多租户与可插拔 Runtime。 containerd 的 namespace 是控制面逻辑隔离域，不同 namespace 下的镜像、容器互不可见，一套 containerd 可同时服务 Kubernetes（k8s.io）、本地调试（default）和 CI 任务等不同租户。此外 containerd 支持通过 Runtime 插件接入 gVisor、Kata Containers 等安全沙箱运行时，在 config.toml 中注册后即可按 Pod 指定 runtimeClassName 运行，实现同一集群内普通容器与安全容器混合调度。

生产部署与监控：从上线到运维

部署方式一：Kubernetes 节点集成。 生产环境最常见的方式是让 kubelet 通过 CRI 直连 containerd。安装完成后确认 /etc/containerd/config.toml 中 CRI 插件未被禁用，sandbox_image 指向的 pause 镜像在集群网络内可拉取。使用 kubeadm 初始化时无需额外配置，kubelet 默认从 /var/run/containerd/containerd.sock 接入 containerd；自定义安装时需在 kubelet 启动参数中指定 --container-runtime-endpoint=unix:///run/containerd/containerd.sock。上线前建议在测试环境验证 crictl ps、crictl images 输出正常，并确认 kubelet 与 containerd 的 cgroup 驱动一致。

部署方式二：Rootless 与边缘场景。 containerd 支持 rootless 模式（无 root 权限运行），通过 containerd-rootless-setuptool.sh 脚本完成安装，适合开发容器与多租户隔离场景。在边缘计算场景，K3s 等轻量 K8s 发行版默认内置 containerd，借助其低内存占用与无守护进程链路的优势，可在树莓派、ARM 网关等受限设备上运行。注意 rootless 模式默认使用 fuse-overlayfs 或 native 快照器，镜像读写性能低于 root 模式，CPU 密集型任务需实测评估。

可观测性。 containerd 暴露 Prometheus 指标端点，需在 config.toml 的 metrics 段设置 address = "127.0.0.1:1338"，然后通过 node-exporter 或直接抓取 http://127.0.0.1:1338/v1/metrics 获取运行中的容器数、镜像拉取耗时、快照操作等指标。日志方面，containerd 默认将容器标准输出交给 kubelet 的日志轮转机制，守护进程自身日志写入 journald，用 journalctl -u containerd -f 跟踪。磁盘监控重点关注 /var/lib/containerd 的镜像层占用，配置 gc 策略定期回收悬空镜像与层数据。

<p class="para-label">避坑清单：</p>

<ul class="dash-list"><li>kubeadm 初始化卡在 ContainerCreating：大部分原因是 sandbox_image 指向的 pause 镜像拉不下来，先把 config.toml 中的 sandbox_image 换成内网可达的 registry.k8s.io 镜像源，再重启 containerd。</li><li>ctr 看不到任何 Pod：ctr 默认操作 default 命名空间，Kubernetes 的镜像与容器在 k8s.io 命名空间，排查时必须加 -n k8s.io，否则误判 containerd 异常。</li><li>kubelet 报 cgroup 驱动不一致：SystemdCgroup 必须与 kubelet 的 --cgroup-driver 一致，K8s 官方推荐 systemd，配置后重启 containerd 和 kubelet。</li><li>1.x 升 2.0 后无法启动：2.0 移除了部分废弃插件与配置字段（如旧版 cri 配置路径），升级前备份 config.toml 并在测试机验证，不要直接覆盖生产配置。</li><li>磁盘被历史镜像占满：生产环境务必配置镜像 GC 策略并接入监控，否则每次发版残留的旧镜像层会持续占用 /var/lib/containerd 空间。</li></ul>

版本迭代

containerd 的演进主线是「从 Docker 内部分离 → CRI 稳定 → 插件化重构」。1.5 补齐生产级 CRI 能力，1.6 成为首个被广泛采用的长期支持版，1.7 是承载 K8s 1.24+ 大规模迁移的 LTS 版本，2.0 于 2025 年 1 月发布，聚焦 v2 API 与插件体系重构（截至训练数据，可能已有更新补丁版本）。

AI 应用场景

常见误区

面试题

参考来源

• webpagecontainerd 官网项目介绍、博客与版本发布入口
• webpagecontainerd GitHub 仓库源码、Issue 与 Release 记录
• webpagenerdctl GitHub 仓库Docker 兼容 CLI 的安装与用法