ContainerRuntime高级运行时containerd架构-Docker-PHP中文网

containerd 是 Docker 1.11 后拆分出的核心容器运行时，Docker Engine 作为其客户端通过 gRPC 调用它，而 Kubernetes 1.20+ 默认使用 containerd 替代 dockerd，二者监听不同 socket、状态不共享。

containerruntime高级运行时containerd架构

containerd 是什么，和 Docker 有什么关系

containerd 不是 Docker 的替代品，而是 Docker 1.11 之后拆出来的核心运行时组件。Docker Engine 实际上是 containerd 的一个客户端封装——它把镜像拉取、容器启停等操作转成 gRPC 请求发给 containerd，后者再调用 runc 创建实际的 Linux 容器。

你直接用 containerd，等于绕过 Docker CLI 和 daemon，更轻、更可控，也更贴近 Kubernetes 的真实运行链路（K8s 1.20+ 默认用 containerd 替代 dockerd）。

如果你在 K8s 节点上查 ps aux | grep containerd，看到进程在跑，说明集群已经在用它
dockerd 默认监听 /var/run/docker.sock；containerd 默认监听 /run/containerd/containerd.sock，路径和协议都不一样
不要试图用 docker ps 查 containerd 直接启的容器——它们彼此不共享状态

怎么手动启动一个容器（不用 docker run）

本质是三步：拉镜像 → 解包到本地存储 → 调用 containerd API 启动。生产环境一般用 ctr（containerd 自带的命令行工具）调试。

ctr image pull docker.io/library/nginx:alpine
ctr run --rm -d --net-host docker.io/library/nginx:alpine my-nginx

--net-host 表示复用宿主机网络命名空间，省去 CNI 配置麻烦；不加的话默认是空网络，容器起得来但没网
ctr 默认不自动创建 rootfs，所以必须先 pull，否则报错 failed to resolve rootfs: no such image
ctr run 是“即时运行”，适合测试；长期服务推荐写 containerd 的 config.toml + 用 crictl（K8s CRI 工具）管理

配置文件里 runtime-type 和 runtime-engine 的区别

containerd 的 config.toml 中，真正决定容器怎么跑的是 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes] 下的配置块，关键字段是：

runtime_type：固定为 "io.containerd.runc.v2"（runc）或 "io.containerd.runhcs.v1"（Windows HC）；改错会直接启动失败，报 unknown runtime type
runtime_engine：已废弃，v1.4+ 忽略；旧文档里写的 runc 或 crun 其实该填在 runtime_type 对应的插件名里

如果要用 crun（更轻量的 OCI 运行时），得先装好二进制，再在配置里写：

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.crun]
runtime_type = "io.containerd.runc.v2"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.crun.options]
  BinaryName = "crun"

常见报错：failed to create containerd task: failed to create shim task: OCI runtime create failed

这个错误出现在 ctr run 或 K8s Pod 启动阶段，根本原因是 runc 执行失败，但 containerd 只透出一层包装错误。真实原因藏在 shim 日志里：

先查 shim 进程：ps aux | grep 'containerd-shim'，找到对应容器的 PID
再看日志：journalctl -u containerd -n 100 | grep -A5 -B5 $PID，或者直接读 /run/containerd/io.containerd.runtime.v2.task/default/$CONTAINER_ID/log.json
常见真凶：
- no such file or directory: unknown → 镜像层损坏，删掉 /var/lib/containerd/io.containerd.content.v1.content/blobs/ 对应 digest 重拉
- permission denied → SELinux 或 AppArmor 拦了 runc，临时关 SELinux 测试：setenforce 0
- invalid argument → cgroup v1/v2 混用，确认内核启动参数含 systemd.unified_cgroup_hierarchy=1 且 containerd 配置里 disabled_plugins = ["cri"] 没误开

containerd 的日志默认不打详细错误，不查 shim 日志就只能猜；而 shim 日志路径、格式、权限又随版本微调，这点最容易卡住人。