Docker 与 Containerd 交互机制简单剖析

#作者：邓伟

一、背景：Docker 架构的演进之路

1.1 从自研运行时到 OCI 标准化

2013 年 Docker 诞生时，采用自研的libcontainer作为容器运行时。随着容器技术标准化推进，2015 年 OCI（Open Container Initiative）成立，定义了容器运行时规范（CRI）和镜像规范。关键转折点：

• 2017 年 Docker 将libcontainer捐赠给 OCI，更名为runc
• 2019 年 Docker Engine 正式采用Containerd作为底层容器运行时管理组件

1.2 现行架构分层模型

Docker CLI
├─ gRPC通信│  └─ Docker Engine（dockerd）│     ├─ gRPC通信│     │  └─ Containerd（/run/containerd/containerd.sock）│     │     ├─ containerd-shim（容器垫片进程）│     │     └─ runc（OCI运行时）└─ 镜像仓库（Docker Hub/私有仓库）

二、核心交互组件解析

2.1 通信协议：gRPC 双向流的应用

关键接口定义（基于 containerd/api）

// containers/v1/container_service.proto
service ContainerService {rpc Create(CreateContainerRequest) returns (CreateContainerResponse) {}rpc Start(StartContainerRequest) returns (StartContainerResponse) {}rpc Delete(DeleteContainerRequest) returns (DeleteContainerResponse) {}}// images/v1/image_service.proto
service ImageService {rpc Pull(PullRequest) returns (stream PullResponse) {} // 流式拉取镜像rpc Push(PushRequest) returns (stream PushResponse) {} // 流式推送镜像
}

通信链路抓包验证

# 监听containerd socket通信strace -f -e trace=network -p $(pidof containerd)# 使用grpcurl查看服务列表grpcurl -unix /run/containerd/containerd.sock list

2.2 镜像生命周期管理交互

2.2.1 镜像拉取流程（以 docker pull 为例）

1. Docker CLI 解析镜像名称，发送ImagePull请求到 Docker Engine

2. Docker Engine 调用 Containerd 的ImageService.Pull接口

3. Containerd 执行以下操作：

   • 解析镜像引用（支持docker.io/library/nginx:alpine格式）

   • 调用distribution库从 Registry 拉取镜像层

   • 将镜像层存储到/var/lib/containerd/io.containerd.content.v1.content

返回链路：通过 gRPC 流返回拉取进度，CLI 显示下载状态

2.2.2 镜像存储格式转换

Containerd 使用Content Addressable Storage (CAS)存储镜像，而 Docker 传统格式为aufs/overlay2，通过containerd-shim实现格式适配：

# 查看Containerd存储的镜像摘要ctr content ls -q | head -n 1
sha256:1a5c2b3d4e5f6789012abc3def456# Docker镜像与Containerd内容的映射关系/var/lib/docker/image/overlay2/repositories.json <-> containerd的boltdb元数据

2.3 容器运行时交互核心流程

2.3.1 容器创建阶段（docker create）

2.3.2 容器启动阶段（docker start）

1. Containerd 通过containerd-shim启动容器进程

2. containerd-shim负责：

   • 保持容器进程与 init 系统的连接

   • 传递信号（SIGKILL/SIGTERM）

   • 收集容器状态信息

1.核心调用链：

containerd/runtime/v2/shim/v2/shim.go:Start()└─ runc.Start()└─ syscall.execve() // 执行容器入口进程

三、源码级交互关键点解析

3.1 Docker Engine 到 Containerd 的接口映射

关键代码路径（Docker 24.0.6 版本）

// docker/daemon/container_engine.go
func (eng *containerEngine) Create(ctx context.Context, req *containerd.CreateContainerRequest) (*containerd.CreateContainerResponse, error) {client, err := eng.client() // 获取Containerd客户端连接return client.Containers.Create(ctx, req)}// 客户端连接初始化
func (eng *containerEngine) client() (*containerd.Client, error) {return containerd.New(eng.config.Containerd.Address, // 默认连接/run/containerd/containerd.sockcontainerd.WithDefaultNamespace("moby"), // Docker专属命名空间)}

3.2 命名空间隔离机制

Docker 通过moby命名空间与 Containerd 其他租户隔离：

# 查看Containerd命名空间ctr namespace lsNAME    LABELSmoby    <none>k8s.io  <none>  # Kubernetes专用命名空间

四、典型问题排查与性能优化

4.1 交互故障诊断工具链

4.2 性能优化关键点

1. 减少 gRPC 调用开销：

   • 批量处理镜像操作（如同时拉取多个镜像层）

   • 使用连接池复用 gRPC 通道

2. 存储驱动优化：

# /etc/containerd/config.toml
[plugins."io.containerd.runtime.v2.task"][plugins."io.containerd.runtime.v2.task.structs"][plugins."io.containerd.runtime.v2.task.structs.linux"]shim = "containerd-shim-runc-v2" # 使用v2版本垫片runtime = "runc"

3. 资源限制传递：Docker 通过–cpu-shares/–memory参数传递的资源限制，最终由 Containerd 转换为 cgroups 配置：

// containerd/runtime/v2/runc/options.go
func (o *LinuxOptions) ToSpec() (*specs.Spec, error) {// 解析CPU配额if o.CPUQuota > 0 {spec.Linux.Resources.CPU.CFSQuota = o.CPUQuota}// 解析内存限制if o.MemoryLimit > 0 {spec.Linux.Resources.Memory.Limit = &memory.Limit}}

五、未来演进：后 Docker 时代的 Containerd

5.1 Kubernetes 对 Containerd 的直接支持

自 Kubernetes 1.20 起，可直接使用 Containerd 作为 CRI 运行时，跳过 Docker 中间层：

# kubelet配置文件apiVersion: kubelet.config.k8s.io/v1kind: KubeletConfiguration
runtimeRequestTimeout: "15m"
containerRuntime: remotecontainerRuntimeEndpoint: unix:///run/containerd/containerd.sock

5.2 功能对比矩阵

六、总结

Docker 与 Containerd 的交互本质是标准化接口（OCI）+ 分层架构（管理平面与运行平面分离的典型实践。理解两者的通信协议（gRPC）、数据流转（镜像存储 / CAS）和生命周期管理（容器创建 / 启动流程），是解决容器化部署中复杂问题的关键。随着 Kubernetes 生态对 Containerd 的直接支持，掌握这一交互机制也成为云原生工程师的核心能力之一。