一文看懂Containerd

一文看懂 Containerd

一句话定位

Containerd 是工业级、OCI 标准的容器运行时(high-level runtime)，CNCF 毕业项目;负责镜像拉取、存储管理、容器生命周期(创建 / 启动 / 停止 / 删除)，不负责镜像构建、Compose、上层编排。Docker 底层本来就依赖它，K8s 在 1.24 正式移除 dockershim 之后，containerd 成为 K8s 默认主流运行时Docker。

分层关系(从上层到内核) Kubelet → CRI 插件 → containerd → containerd-shim → runc → Linux Kernel(namespace/cgroup) Docker 链路：docker cli → dockerd → containerd → shim → runc → kernel

一、发展简史

2017：Docker 将内部容器管理模块拆分独立项目 containerd，捐赠 CNCF

2019：CNCF 毕业，正式成为云原生标准组件

内置 CRI 插件：不用额外部署 cri-containerd，原生对接 K8s

遵循 OCI 两套规范：镜像规范(image-spec)、运行时规范(runtime-spec)，镜像跨工具互通Docker

二、核心架构(C/S 架构，gRPC)

Containerd 是后台守护进程 containerd，监听 unix socket /run/containerd/containerd.sock，模块化插件化设计：

gRPC API 层：对外提供原生 API + CRI API(K8s 使用)，多客户端接入

Core 核心模块：管理 Namespace、任务(Task)、事件、元数据;namespace 用来隔离多租户，不同命名空间镜像 / 容器互不干扰(ctr 默认 ns=default，K8s 使用 k8s.io)

Content Store：内容寻址存储，保存镜像 blob、manifest，去重存储镜像层

Snapshotter 快照器：构建容器 rootfs。常用 overlayfs;也支持 devmapper、btrfs、zfs;负责镜像层只读 + 容器读写层合并

Runtime(Runtime v2)：通过 shim 调用底层 OCI runtime(默认 runc)

containerd-shim：非常关键。容器真正父进程;runc 创建完容器就退出，shim 留下来托管容器进程、转发信号、收集 IO、防止 containerd 重启导致容器挂掉

可替换 runtime：Kata Containers、gVisor(安全沙箱容器)

CRI Plugin：K8s 专用插件，适配 CRI 接口，对接 CNI 管理 Pod 网络，管理 pause 沙箱容器containerd

重点：containerd 不会直接调用 runc 常驻管理容器，是 shim 负责托管容器。

三、核心能力清单

✅ 镜像：pull、push、list、import、export、存储去重 ✅ 容器生命周期：create /start/stop /pause/delete ✅ 快照管理：rootfs 分层读写 ✅ 日志、事件流、容器 IO 转发 ✅ 插件扩展：快照器、runtime、监控、流插件 ❌ 不自带镜像构建(没有 docker build;想构建镜像用 nerdctl build) ❌ 不自带编排、不自带卷高级管理、不自带 docker compose

四、三个命令行工具，别搞混

ctr：自带原生 cli，对接 containerd 原生 API;仅调试使用，不友好，不推荐生产日常管理

ctr images pull docker.io/library/nginx:alpine

ctr run docker.io/library/nginx:alpine nginx-demo

nerdctl：社区工具，兼容 docker 语法(nerdctl run/build/push)，支持构建镜像，开发运维首选

crictl：CRI 客户端，专门调试 K8s CRI 链路，只能看到 Pod / 容器，看不到 containerd default 命名空间资源

crictl ps

crictl images

五、Containerd vs Docker vs runc(高频面试区分)

Docker：完整容器平台(CLI + dockerd + build + compose + volume + network + containerd)，面向开发者;dockerd 是上层封装

Containerd：容器运行时，只管镜像 + 容器生命周期，无构建能力;Docker 底层依赖 containerd，K8s 直接对接 containerd

runc：低阶 runtime，最小工具，严格实现 OCI runtime spec;直接调用 Linux 系统调用，创建 namespace、cgroup，启动容器进程;只负责启动，不管理镜像、存储

一句话：runc 负责 “造容器”，containerd 负责 “管容器和镜像”，Docker 是带构建能力的上层平台

六、K8s 为什么弃用 dockershim，转向 containerd?

K8s 的 CRI 是标准接口，Docker 原生不支持 CRI，早年靠 dockershim 垫片做适配，垫片维护成本高、链路更长

链路对比

旧：kubelet → dockershim → dockerd → containerd → shim → runc

新：kubelet → CRI (containerd 内置) → containerd → shim → runc 链路变短、减少进程开销、故障面更小，资源占用更低

K8s 只需要容器运行能力，不需要 dockerd 里 build/compose 等多余功能，架构更简洁

标准化：CRI-O、containerd 都实现 CRI，运行时可替换，不绑定 Docker

注意：不是 K8s 不能跑 Docker 镜像，镜像是 OCI 标准，镜像完全互通

七、容器启动完整流程(containerd 视角)

客户端(kubelet/ctr/nerdctl)通过 gRPC 请求 containerd，拉取镜像

containerd 从 registry 拉取 manifest、layer blob，存入 content store

snapshotter 基于镜像只读层，创建读写快照(rootfs)

containerd 创建 Task，启动 containerd-shim 进程

shim 调用 runc，传入 config.json + rootfs

runc 调用 Linux clone () 创建 namespace、配置 cgroup、挂载 rootfs，启动容器主进程

runc 退出;shim 持续托管容器进程，转发 stdout/stderr、信号;containerd 监控 shim 状态

八、优势与短板

优势

轻量稳定，模块化，故障面小，适合大规模集群

原生支持 CRI，K8s 官方首选，生态成熟

OCI 标准，镜像跨平台互通，runtime 可插拔(Kata/gVisor)

存储内容寻址，镜像层自动去重，节省磁盘

shim 隔离设计：containerd 重启，容器进程不会挂

资源开销低于 dockerd

短板

原生无 build，无 compose，开发体验弱于 Docker;需要搭配 nerdctl

ctr 命令体验差，学习成本高于 docker cli

配置项多(快照器、cni、runtime、registry)，初期调试门槛高

网络依赖 CNI，不像 Docker 自带内置网桥网络

九、常见配置文件与排错要点

默认配置：/etc/containerd/config.toml 重点配置项：

root：数据目录(默认 /var/lib/containerd)

snapshotter：默认 overlayfs

[plugins."io.containerd.grpc.v1.cri"]：CRI 配置，镜像仓库、sandbox 镜像(pause)、cni 路径

Runtime：runc 路径、root 路径

排错思路：

检查 containerd 进程和 sock 文件

crictl info 验证 CRI 就绪状态(RuntimeReady / NetworkReady)

区分：ctr 看 default 命名空间;crictl 看 k8s.io 命名空间，互相看不到资源，这是新手高频踩坑点

十、总结一句话

Containerd 是现代云原生的容器底座：Docker 的底层引擎，K8s 的标准运行时;它剥离了构建、编排等上层能力，专注稳定、标准地管理镜像和容器生命周期，是兼顾标准化、性能、可扩展性的中间层。