上游 (dockerd/kubelet)
containerd 核心
下游 (shim/runc/容器)
上游 — 通过 gRPC 调用 containerd
dockerd
Docker Engine
kubelet
Kubernetes
crictl
调试工具
gRPC API
containerd 核心
gRPC API 层
Image
镜像管理
Container
容器管理
Task
进程管理
Events
事件订阅
核心子系统
Content Store
content
镜像层数据
Metadata Store
metadata
boltDB
Snapshotter
snapshot
overlayfs / devmapper
fork + exec
下游 — 每个容器对应一个 shim + 一个 runc 实例
容器 A
containerd-shim
托管容器进程生命周期
OCI exec
runc
创建 namespace + cgroup
启动
容器进程
nginx: master
容器 B
containerd-shim
托管容器进程生命周期
OCI exec
runc
创建 namespace + cgroup
启动
容器进程
redis-server
容器 C
containerd-shim
托管容器进程生命周期
OCI exec
runc
创建 namespace + cgroup
启动
容器进程
python app.py
containerd 架构 vs Docker 早期架构 — 为什么这样拆分？
Docker 早期 (v1.11 之前) — 单体架构
dockerd (单体)
镜像 + 容器 + 网络 + 日志...
直接管理
容器进程
父进程 = dockerd
❌ dockerd 重启 → 所有容器被杀
❌ 只能通过 Docker API 调用
❌ K8s 需要 dockershim 适配层
❌ 只能通过 Docker API 调用
❌ K8s 需要 dockershim 适配层
现代架构 (containerd) — 分层解耦
dockerd / kubelet
上层入口 (可独立重启)
gRPC
containerd
标准容器运行时
fork
shim → 容器进程
父进程 = shim (dockerd 重启不影响)
✔ dockerd/kubelet 重启 → 容器不受影响
✔ 标准化 gRPC API，多调用方
✔ K8s 直接通过 CRI 对接，无需 dockerd
✔ 标准化 gRPC API，多调用方
✔ K8s 直接通过 CRI 对接，无需 dockerd
💡 containerd 是什么？
containerd 是业界标准的容器运行时，负责管理容器的完整生命周期。
上游：dockerd、kubelet 等通过 gRPC API 调用 containerd 创建容器
核心：镜像管理 + 容器元数据 + 文件系统快照
下游：为每个容器 fork 独立的 containerd-shim → runc → 容器进程
点击组件查看详细说明。
containerd 是业界标准的容器运行时，负责管理容器的完整生命周期。
上游：dockerd、kubelet 等通过 gRPC API 调用 containerd 创建容器
核心：镜像管理 + 容器元数据 + 文件系统快照
下游：为每个容器 fork 独立的 containerd-shim → runc → 容器进程
点击组件查看详细说明。