containerd 是 docker 架构中真正负责容器“跑起来”的核心运行时组件，它不处理镜像构建、命令行交互或编排逻辑，只专注安全、稳定地管理容器生命周期，并通过 containerd-shim-v2 和 runc 调用内核能力实现隔离进程。
Containerd 是 Docker 架构中真正负责容器“跑起来”的核心运行时组件，它不处理镜像构建、命令行交互或编排逻辑，只专注一件事：安全、稳定地管理容器的生命周期。
Containerd 在 Docker 架构中的位置
Docker 不是单体进程，而是分层协作的架构：
-
Docker CLI：用户输入
docker run等命令，通过 REST API 发送给 Docker Daemon - Docker Daemon（dockerd）：接收请求后，把容器创建、启动、停止等具体操作，委托给 Containerd 执行
- Containerd：作为轻量级守护进程，接管所有底层容器管理任务，并进一步调用 runc 创建真实容器进程
- runc：OCI 标准实现，真正调用 Linux kernel 的 namespace 和 cgroups，启动隔离进程
为什么 Docker 要依赖 Containerd？
这是 Docker 架构解耦和专业化演进的结果：
- 早期 Docker 把构建、镜像、网络、运行时全包在一个二进制里，维护复杂、升级困难
- 2016 年起，Docker 主动将容器运行时模块剥离为独立项目 Containerd，提升稳定性与可嵌入性
- Containerd 更小、更稳、接口标准（gRPC + OCI），既能服务 Docker，也能直接被 Kubernetes 调用
- 现在 Docker Desktop 和 Docker Engine 都默认使用 Containerd 作为底层运行时，只是对用户做了透明封装
Containerd 不等于 Docker，但它是 Docker 跑起来的关键
你可以这样理解两者关系：
- Docker 是面向开发者的“应用商店+快递员+管家”：帮你打包（Dockerfile）、拉镜像、启容器、连网络、看日志
- Containerd 是后台的“厂房调度中心”：只管接单（接收请求）、安排产线（调用 runc）、监控流水线（shim 进程）、保证不停工（daemon 崩溃不影响容器）
- 没有 Containerd，Docker 就无法真正运行容器；但不用 Docker，你也能直接用
nerdctl或ctr操作 Containerd 来管理容器
实际运行时的调用链很清晰
当你执行 docker run nginx:alpine，背后发生的是：
- Docker CLI → dockerd（REST）→ Containerd（gRPC）→ containerd-shim-v2 → runc → Linux kernel
- 其中 shim 进程是关键：每个容器独占一个 shim，让 containerd 主进程重启时，容器仍持续运行、状态不丢失
- 整个链路严格遵循 OCI 规范，所以同一套镜像和配置，既能在 Docker 里跑，也能在 Kubernetes + Containerd 环境里跑
