Docker与containerd深度集成：从docker run调用链到生产实践

如果你已经用 Docker 用了几年，多少会听到 containerd 这个名字。平时我们敲 docker ps、docker run 时，真正干活的不只是 dockerd，还有一个隐藏在后面的 containerd，整套 Docker 与 containerd 的集成关系，才是容器稳定运行的地基。很多人以为 containerd 是 Kubernetes 场景才用的东西，其实从 Docker Engine 1.11 开始，它就已经成为 Docker 默认的容器运行时管理组件。这篇文章我想把 Docker 与 containerd 的集成链路完整拆开：从一条 docker run 的调用链讲起，到 Linux 和 Docker Desktop 下的环境差异、配置对接、高频故障排查，再到生产环境直接使用 containerd 的取舍。无论你是刚接触容器的小白，还是已经在用 Kubernetes 的运维，都应该能从中找到对自己有用的细节。

1. 从 dockerd 到 containerd：一条 docker run 的执行链路到底有多长

1.1 Docker 不是一个进程，而是一套“前台 + 后台 + 工人”的组合

很多人理解 Docker，就是“装一个 docker 命令，跑容器”。但 Docker Engine 并不是一个单体二进制，它至少包含四层：

• docker CLI：你敲的命令行客户端。
• dockerd：Docker 的守护进程，负责 API、镜像管理、网络、卷等上层功能。
• containerd：容器运行时管理层，负责镜像解包、容器生命周期管理、快照和元数据存储。
• containerd-shim：每个容器一个 shim 进程，它是 containerd 与容器运行时的中间人。
• runc：真正调用 Linux 内核能力创建容器的底层工具，生成 cgroups、namespace、rootfs。

2017 年 Docker 把 containerd 捐赠给 CNCF 以后，这个分工一直保持到今天。所以你在 Linux 上执行 ps aux | grep containerd 会看到好几个进程：有 daemon 进程，也有以 docker-containerd-shim 或 containerd-shim 命名的进程。每一个运行中的容器，背后都有一个 shim 在“守着”。

1.2 一条 docker run 命令的完整调用链

如果你执行 docker run -d --name test nginx:alpine，实际发生的事远比表面复杂：

1. docker CLI 通过 /var/run/docker.sock 调用 dockerd 的 REST API。
2. dockerd 收到请求后，把镜像名 nginx:alpine 解析成镜像 ID，检查本地是否已有，没有就去 registry 拉取。
3. dockerd 把“创建容器”的请求发给 containerd，通过 gRPC 协议连接 /var/run/docker/containerd/containerd.sock。
4. containerd 创建容器对象，准备 rootfs、mount 点，然后启动一个 containerd-shim 子进程。
5. shim 通过 runc 的二进制去实际创建并启动容器进程。
6. runc 完成 namespace/cgroup/rootfs 等各种内核配置后，容器进程开始运行。
7. runc 退出，shim 作为容器的“父亲”一直存活，负责接管标准输入输出、转发信号、上报退出状态。
8. containerd 再把结果返回给 dockerd，dockerd 最后告诉你 container id。

这个链路看起来长，但每一步都是必要的。如果 runc 直接作为容器父进程，容器退出后就没人和 containerd 保持联系了；shim 的存在，让 dockerd 重启、containerd 重启时容器还能继续跑。这也是为什么你可以放心重启 Docker 服务，已经运行的容器不会同步消失。

1.3 为什么要这个“中间商”？直接 runc 不行吗

理论上你可以直接用 runc 创建容器，但现实世界不会这么做。runc 只是“底层的执行者”，它不知道镜像怎么拉取、容器元数据怎么保存、日志怎么收集。containerd 在这个位置扮演的是“调度总管”：

• 统一管理镜像层解压和挂载。
• 保存容器状态和元数据。
• 提供稳定 gRPC API 给上层调用。
• 可以通过插件加载不同的运行时，不一定非要用 runc。

这就像一家餐厅：docker 是门口接待客人的前台，dockerd 是排号系统，containerd 是后厨总管，runc 才是真正炒菜的厨师，shim 是上菜后守在包厢里的服务员。每一层都有自己的职责，替换某一层不会影响整条链路。

2. 版本选择与环境准备：Linux 和 Docker Desktop 下的集成差异

2.1 怎么确认当前 Docker 集成的 containerd 版本

不同 Docker 版本内置的 containerd 版本不同，排查问题前一定要先确认版本。命令很简单：

bash复制docker version

输出里有一项 containerd，显示的是 Docker 内嵌的 containerd 版本。也可以通过 docker info 看更多细节，比如是否为 containerd 快照存储、运行时种类等。

另外，Linux 下安装 Docker 时，发行版包管理器会同时安装一个独立的 containerd.io 包。这个包里的 containerd 和 Docker 编译时内嵌的 containerd 通常一致，但有独立 systemd 服务：

bash复制systemctl status containerd

如果你看到 containerd 服务没启动，那么 Docker 启动也会跟着失败。这条依赖关系在生产环境中特别容易忽略。

2.2 Linux 下“Docker 自带 containerd”与“独立 containerd”的差别

这里有一个容易混淆的地方：Docker 使用的 containerd 并不一定等于你手动安装的独立 containerd。

• 用 Docker 官方源安装：yum install docker-ce 或 apt install docker.io 时，会自动安装 containerd.io 包，Docker 会使用这个系统级 containerd。
• 用 docker-ce 静态二进制包手动安装：里面也打包了 containerd，但未必有 systemd unit 文件。
• 单独部署 containerd 给 Kubernetes 用：这时候绕开 Docker，由 kubelet 通过 CRI 直接调用 containerd，和 Docker 没有任何关系。

版本上，Docker 官方对 containerd 的兼容性说明通常不会细到“哪个 containerd 配哪个 Docker 绝对没问题”，但大版本不对时，可能出现 dockerd 启动成功但创建容器失败。我自己的建议是：用发行版源或 Docker 官方源统一安装，不要在一个机器上混用不同渠道的 containerd 二进制。

2.3 Docker Desktop 的 containerd 其实跑在虚拟机里

很多人在 Windows 或 macOS 上用 Docker Desktop，感觉和 Linux 一样。但 Docker Desktop 实现方式完全不同：它内部启动一台轻量级 Linux 虚拟机，containerd、dockerd 全部运行在虚拟机里面。Windows 上要开启基于 WSL2 或 Hyper-V 的虚拟化，否则启动就直接报错。

热词里有一个很典型的报错：docker desktop failed to start because virtualisation support wasn't detected。这不是 Docker 本身坏了，而是宿主机的虚拟化功能没开启。在 Windows 上表现为：

• BIOS/UEFI 中的 Intel VT-x 或 AMD-V 未开启。
• Windows 功能里的“适用于 Linux 的 Windows 子系统”和“虚拟机平台”没勾选。
• 已经安装了 Docker Desktop，但切换了 WSL 发行版导致集成失败。

Docker Desktop 里如果开启了“Use containerd for pulling and storing images”，镜像存储会从 Docker 的 graphdriver 切换到 containerd 的快照机制，很多镜像相关操作行为也会发生变化。这一点在 2.3 和 2.4 都会影响排错。

2.4 不依赖 Docker，直接用 containerd 管理容器

如果你想搞清楚 containerd 的“真面目”，建议抛开 Docker，直接用 containerd 自带命令 ctr 跑一个容器：

bash复制ctr images pull docker.io/library/nginx:alpine
ctr run docker.io/library/nginx:alpine nginx-test

这里有个天然的坑：ctr 默认只认识 containerd 自己的命名空间，Docker 创建的容器在 moby 命名空间里，而 ctr 默认看到的命名空间是 default。你在机器上明明用 docker ps 能看到容器，用 ctr c list 却看不到，很正常，因为你没有加 --namespace moby。

bash复制ctr --namespace moby c list

另一个更友好的工具是 nerdctl，它的命令风格和 Docker CLI 几乎一样，是 containerd 社区推荐的替代品，后面会说。在排除 Docker 问题时，这两个工具能帮你确认问题到底出在 Docker 上层，还是 containerd 下层。

3. 配置协同：daemon.json 和 containerd 的参数对接逻辑

3.1 dockerd 怎么找到 containerd

Docker 默认通过 socket 文件与 containerd 通信，Linux 下通常是：

text复制/var/run/docker/containerd/containerd.sock

如果你在 daemon.json 里改过 containerd 的路径，或者在容器里使用了 Docker Desktop，这个 socket 可能在不同位置。可以使用 docker info 看，也可以检查 dockerd 的启动参数：

bash复制ps aux | grep dockerd

重点看有没有 --containerd 参数。例如：

bash复制/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock

如果这里指定的 socket 和 containerd 实际监听的 socket 不一致，dockerd 就会反复启动失败。

3.2 daemon.json 里值得留意的关键项

/etc/docker/daemon.json 是 Docker 守护进程的配置入口。与 containerd 集成最相关的是 features 字段：

json复制{
  "features": {
    "containerd-snapshotter": true
  }
}

开启这个特性后，Docker 从 graphdriver 切换为 containerd 的快照存储。镜像拉取、解包、容器的可写层都由 containerd 管理。它带来的好处：

• 减少镜像文件重复占用。
• 能利用 containerd 对 OCI 镜像标准更好的支持。
• 为后续使用更多 containerd 生态工具做了铺垫。

但要注意，切换存储后，之前本地的 docker images 缓存不会自动迁移，相当于原来的镜像要重新拉取一次。如果你有大量离线镜像，或者依赖旧版 overlay2 行为的老项目，验证后再开这个开关。

3.3 containerd 自己的 config.toml

containerd 的配置在 /etc/containerd/config.toml，不管是不是给 Docker 用，这份配置都会影响行为。常见的几项：

toml复制version = 2
root = "/var/lib/containerd"
state = "/run/containerd"

[plugins."io.containerd.grpc.v1.cri"]
sandbox_image = "registry.k8s.io/pause:3.9"

[plugins."io.containerd.snapshotter.v1.overlayfs"]
root_directory = "/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs"

• version = 2：新版本建议用配置格式 v2。
• root：containerd 的数据目录。
• [plugins."io.containerd.grpc.v1.cri"]：CRI 插件配置，Kubernetes 环境常用它指定 pause 沙箱镜像。
• overlayfs 快照器：默认负责把镜像层和可写层叠加。

Docker 集成情况下，这些配置主要影响镜像存储位置和挂载参数。如果磁盘被占满，通常在 /var/lib/containerd 和 /var/lib/docker 两个目录要一起查。

3.4 CRI 插件是不是 Docker 也要用

不少初学者误解“containerd = CRI = Kubernetes”。实际上 containerd 的 CRI 插件是给 kubelet 用的，Docker 并不通过 CRI 接口操作容器。Docker 通过 containerd 的原生 API 来管理容器。

这意味着你可以在同一台机器上同时跑 Docker 和 Kubernetes，由 containerd 处理两套调用。不过生产上不建议这么干，因为镜像命名空间、资源占用、安全审计会变得混乱。理解这一点对排查“Docker 正常但 kubelet 找不到容器”这类问题很有帮助：不是 containerd 的问题，是你没分清调用接口和命名空间。

4. 日常运维中的底层映射：常用命令到底作用在哪个组件

4.1 docker run 与容器生命周期

平时你执行 docker run、docker start、docker stop，这些命令最终都会转化为 containerd 的任务操作。

• docker run：dockerd 创建容器 + containerd 启动 task。
• docker start：dockerd 请求 containerd 重新启动已有 task。
• docker exec：dockerd 通过 containerd 在已有 task 里创建新进程。
• docker rm：dockerd 删除容器元数据，containerd 清理 task，shim 退出。

只要 containerd 卡住或 socket 不可达，连 docker ps 都可能超时。遇到这种情况，先别反复重启 dockerd，先看 containerd 的日志：

bash复制journalctl -u containerd --since "10 minutes ago" --no-pager

我见过很多次 docker ps 卡住，原因是 /var/lib/containerd 所在磁盘满了，containerd 无法记录新状态。这时候 docker 命令一直转圈，直接 systemctl restart docker 反而可能让 metadata 不一致，正确操作是先清理磁盘。

4.2 docker stop 的 SHIM 层信号传递

docker stop 默认等待容器优雅退出，超时时间 10 秒，然后强制杀掉。很多人以为这是 dockerd 直接给容器进程发信号，实际上信号通过 containerd 转发给 shim，再由 shim 发到容器里的 1 号进程。

如果容器里的 1 号进程不处理 SIGTERM，10 秒后 dockerd 会请求 containerd 发 SIGKILL。你可以在 docker events 里看到：

text复制stop
die

在 containerd 和 shim 的日志里，能更精确地看到信号发送时间。排查“容器停不掉”时，这个链路很重要：到底是容器不响应，还是 shim 和 containerd 之间断了。

4.3 docker logs 与容器标准输出

容器的日志通常写在哪？默认情况下，dockerd 通过 containerd 把容器的 stdout/stderr 拿到，再交给 docker 自己的 log driver。你执行 docker logs 时看到的内容，并不存在 /var/lib/docker/containers 的文件里吗？其实大部分默认 json-file 日志会存在 /var/lib/docker/containers/<id>/<id>-json.log 里。

但如果你启用了 containerd-snapshotter，并且把日志驱动改成了 local 或 journald，路径就变了。排查日志丢失问题，不要只盯着 docker 目录，还要看 containerd 状态和容器 rootfs 挂载是否正常。

4.4 资源限制由 cgroup 接管

docker run --cpus=1 -m 512m 这类选项，最终由 runc 写入 cgroup。containerd 在这里的主要工作不是计算 CPU 配额，而是把 dockerd 的配置转换为 OCI spec，再传给 runc。如果 containerd 不兼容某些 cgroup v2 特性，资源限制可能不生效。

CentOS 7 升级 Docker 后遇到的 cgroup 问题，很多就是新旧内核、新旧 containerd 对 cgroup v1/v2 处理不同造成的。如果 docker update 后 docker stats 看到的限制没变，可以检查宿主机 cgroup 版本：

bash复制stat -fc %T /sys/fs/cgroup/

5. 集成层故障排查：权限、启动失败与镜像下载慢

5.1 permission denied while trying to connect to the docker api

这个报错几乎是 Docker 新人必踩的坑。字面意思是无法连接 Docker API，常见原因是当前用户没有访问 /var/run/docker.sock 的权限。

bash复制docker ps
# permission denied while trying to connect to the docker api

解决方式：

bash复制sudo usermod -aG docker $USER
newgrp docker

加了 docker 组之后，还是报错，就要考虑是不是 Docker 服务本身有问题，socket 文件不存在。另一个隐藏原因是：你手动安装了 containerd 并把 /var/run/docker/containerd/containerd.sock 的权限改了，导致 dockerd 启动后没监听 /var/run/docker.sock。检查一下：

bash复制ls -l /var/run/docker.sock

正常情况下属主是 root:docker。如果属主变成别的用户，或者 socket 文件没了，重启 docker 前先确认 containerd 在运行。

5.2 Docker Desktop 启动失败和虚拟化支持

Windows 上 Docker Desktop 启动失败的报错里，常见下面几种：

• virtualisation support wasn't detected
• Docker Desktop failed to start
• WSL distro terminated abruptly

这些和 containerd 集成有关系，但根因通常在 Windows 层。排查顺序：

1. 打开“Windows 功能”，确认“虚拟机平台”和“适用于 Linux 的 Windows 子系统”都勾选。
2. 确认 BIOS 里的虚拟化开启。
3. 执行 wsl --status 看默认发行版是否正常。
4. 如果原来用过 VirtualBox 或旧版 Docker Toolbox，可能和 Hyper-V 冲突，需要关闭或调整启动模式。
5. 最后重置 Docker Desktop，让它重新初始化虚拟机里的 containerd 和 dockerd。

Docker Desktop 会在启动时初始化一台 Linux 虚拟机，虚拟机里面的 containerd 如果初始化失败，也会导致 Docker Desktop 永远卡在 starting。遇到这种情况，可以打开 Docker Desktop 的 Troubleshoot 面板查看日志，也可以进入 wsl -d docker-desktop 检查服务。

5.3 docker pull 报错 failed to decode referrers index

这个报错出现的场景通常和 containerd image store 有关。搜索热词里的 docker desktop docker pull mysql 报错failed to decode referrers index: invalid，我遇到过类似情况：Docker Desktop 开启了 containerd 镜像存储，拉取某个带 OCI artifact 的镜像时，containerd 解析 referrers index 出错。

解决办法没有统一版本，但可以按这个顺序处理：

1. 先重试一次，有些镜像是网络中断导致的 metadata 不完整。
2. docker system prune -a 清理无效缓存，注意会删除所有本地镜像。
3. 暂时关闭 Docker Desktop 的 Use containerd for pulling and storing images，退回旧版镜像存储。
4. 升级 Docker Desktop 到新版本，这个报错在后续版本里修过多次。

如果是在 Linux 上用 Docker 启用了 containerd-snapshotter 也出现这个报错，可以考虑升级 containerd.io，或者临时把 daemon.json 里的 containerd-snapshotter 设为 false。

5.4 启动 docker 服务失败，先分清楚是 dockerd 失败还是 containerd 失败

生产服务器上，一条 systemctl start docker 失败，日志可能只告诉你“Job for docker.service failed”。拆分思路：

bash复制systemctl status docker
journalctl -u docker -n 100 --no-pager
systemctl status containerd
journalctl -u containerd -n 100 --no-pager

如果 containerd 日志里有 failed to load cni config 或 failed to mount overlayfs，说明 containerd 启动环境有问题；如果 containerd 正常，dockerd 报 could not connect to containerd，再看 socket 路径、权限、版本。

这个排查思路我在处理 CentOS 7 升级 Docker、Ubuntu 上手动安装 containerd 的案例里反复用到。永远不要只看 Docker 的日志，containerd 才是更靠近内核的那一环。

6. 生产化进阶：直接使用 containerd 作为运行时的集成取舍

6.1 Kubernetes 为什么抛弃 dockerd，却保留了 containerd

Kubernetes 在 1.24 之后移除了 dockershim，意味着 kubelet 不再直接支持 Docker。但 Kubernetes 一直可以使用 containerd 作为容器运行时。这不是说“Docker 死了”，而是把容器运行时层进一步收窄到 containerd。

关键点在于：

• Docker 对 Kubernetes 而言多了一层 dockerd 抽象，而 kubelet 需要的是标准 CRI。
• containerd 原生实现了 CRI 接口，效率更高，故障面更小。
• Docker 仍然是一个优秀的开发工具，尤其在镜像构建、本地调试、Compose 编排场景。

我在生产里切换时，最明显的感受是：节点上进程变少了，内存占用小了一些，日志链路也更短。但如果你平时只用 Docker，切到 containerd 后需要适应另一个工具集。

6.2 用 nerdctl 和 ctr 接管日常操作

生产环境如果已经完全去掉 Docker，那么日常排查需要用到：

bash复制ctr --namespace k8s.io c list
ctr --namespace k8s.io task list
ctr --namespace k8s.io images list

k8s.io 是 Kubernetes 使用 containerd 时的默认命名空间。如果你用 Docker 习惯了一堆 docker ps/exec/logs，直接上 ctr 会非常痛苦，因为它不提供 exec 这种高层便捷命令。

解决方案是使用 nerdctl，它提供接近 Docker CLI 的体验：

bash复制nerdctl --namespace k8s.io ps
nerdctl --namespace k8s.io exec -it test sh
nerdctl --namespace k8s.io build -t myapp .

nerdctl 还支持 compose，但功能不如 Docker Compose 完整。生产环境我建议把它当成调试工具，而不是完全替代 Docker 的开发体验。

6.3 镜像构建和镜像管理怎么和 containerd 集成

没有 Docker 的情况下，怎么构建镜像？整体我有几个可选路径：

• 使用 buildkit 的独立二进制，生成 OCI/Docker 镜像。
• 使用 nerdctl build，它会自动调用 buildkit。
• 使用 podman build 也能生成兼容镜像，再推送到 registry。
• 使用 skopeo 或 crane 做镜像复制和格式转换。

如果你还保留 Docker 作为开发端的镜像构建工具，然后通过私有 registry 分发镜像到 containerd 节点，这就是最常见的集成模式：CI 里用 Docker 构建，生产节点上用 containerd 拉取和运行。

这里有个容易踩的坑：镜像的 entrypoint 和 shell form 在 Docker 上构建没问题，切到 containerd 后，因为缺少 docker exec 层的某些封装，调试时行为看起来不一样。实际上底层都是 runc，问题通常出在你的调试命令直接调用了 ctr 而没设置好环境变量。比如 nerdctl 默认的 rootless 命名空间和 root 命名空间不同，命令行为也会不一样。

6.4 从 Docker 迁移到 containerd 的几条实战建议

如果你决定把生产环境从 Docker 切换为 containerd，我的建议是按这个顺序来：

1. 先用一台测试节点，安装 containerd，配好 config.toml。
2. 用 ctr images pull 和 nerdctl run 跑一遍核心业务镜像。
3. 验证网络、日志、监控采集是否正常。
4. 再接入 Kubernetes，或替换容器运行时。
5. 最后再删掉 Docker 服务，不要一上来就卸载。

迁移过程中最容易被忽略的：

• 镜像命名空间差异：Docker 的镜像在 containerd 里会自动安排到不同命名空间，需要统一命名。
• 私有仓库证书：Docker 的 daemon.json 里配置 insecure-registries 和 registry-mirrors，containerd 里要在 config.toml 配置 [plugins."io.containerd.grpc.v1.cri".registry]。
• 日志轮转：Docker 有 log-opts max-size，containerd 要单独配置 CRI 的 log 轮转，否则 /var/log/containers 可能爆掉。

6.5 安全加固和资源隔离

不管用 Docker 还是 containerd，底层都是同一套内核隔离技术。区别在于你暴露给用户的入口：

• 使用 Docker 时，用户接触的是 /var/run/docker.sock，权限控制非常重要。
• 使用 containerd 时，ctr 默认是 root 操作的，普通用户不能乱连。
• 如果多团队共享一个节点，建议在 Kubernetes 层面做 namespace 隔离和 RBAC，而不是让大家直接操作 containerd。

生产环境还可以开 rootless containerd，但和 rootful 相比，需要处理用户命名空间、端口映射、挂载权限等额外问题。我个人的经验是：刚上手不要追求 rootless，先用 rootful 把业务跑稳，再考虑用 rootless 加固。

另一个容易忽略的点是，containerd 的 snapshotter 直接决定磁盘使用和性能。overlayfs 是主流默认，但在某些内核老旧的系统上，可能要退回 native 快照器。切换快照器不会自动迁移已有镜像，所以确定性能瓶颈前不要乱动。

最后再说一点实际的体会

我已经不只一次遇到这种情况：一个环境里同时装了 Docker、独立 containerd、Kubernetes，出了问题后大家都很迷茫，不知道容器到底归谁管。其实只要先相信一条标准——docker 管 dockerd，dockerd 管 containerd，containerd 管 shim 和 runc——排查方向就不会乱。我自己在调试时最喜欢做的测试，是在同一台机器上用 docker run 跑一个 nginx，再用 ctr --namespace moby c list 看到同一个容器。那一刻，Docker 和 containerd 的集成关系就完全具象化了。如果你也想彻底理解这套集成机制，不妨从这一步开始，亲手观察一下宿主机上的进程树，远比死记架构图有用得多。