Containerd容器运行时

约 1551 字大约 5 分钟

containerdruntime

2025-06-20

containerd 是一个工业级的容器运行时，被 Docker Engine、Kubernetes 和许多云平台作为底层容器管理组件。在 Kubernetes 1.24+ 移除 dockershim 后，containerd 成为最主流的 CRI 运行时。

containerd 架构

OCI 运行时规范

OCI（Open Container Initiative）定义了两个核心规范：

Runtime Specification

定义容器的配置、执行环境和生命周期：

{
  "ociVersion": "1.0.2",
  "process": {
    "user": {"uid": 1000, "gid": 1000},
    "args": ["/app/server"],
    "env": ["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"],
    "cwd": "/app"
  },
  "root": {
    "path": "rootfs",
    "readonly": true
  },
  "linux": {
    "namespaces": [
      {"type": "pid"},
      {"type": "network"},
      {"type": "mount"},
      {"type": "ipc"},
      {"type": "uts"}
    ],
    "resources": {
      "memory": {"limit": 536870912},
      "cpu": {"quota": 100000, "period": 100000}
    }
  }
}

Image Specification

定义镜像格式，包括 manifest、config 和 layers。

runc

runc 是 OCI Runtime Specification 的参考实现，负责实际创建和运行容器：

# 直接使用 runc（底层操作）
mkdir -p /mycontainer/rootfs
# 导出文件系统
docker export $(docker create busybox) | tar -C /mycontainer/rootfs -xf -
# 生成 OCI spec
cd /mycontainer && runc spec

# 运行容器
runc run my-container

# 查看运行中的容器
runc list

runc 的核心职责：

设置 Linux namespaces（pid、net、mnt、ipc、uts、user）
配置 cgroups 资源限制
设置 seccomp 和 AppArmor 安全策略
执行容器进程

containerd-shim

shim 进程是 containerd 和 runc 之间的中间层，每个容器对应一个 shim：

shim 的关键作用：

解耦 containerd 和容器进程：containerd 重启不影响容器
收集容器退出状态：作为容器父进程等待子进程退出
管理容器的 stdin/stdout/stderr
支持 containerd 无损升级

CLI 工具对比

ctr（containerd 原生 CLI）

# 拉取镜像
ctr images pull docker.io/library/nginx:1.25

# 列出镜像
ctr images list

# 运行容器
ctr run -d --net-host docker.io/library/nginx:1.25 my-nginx

# 查看容器
ctr containers list

# 查看任务（运行中的容器进程）
ctr tasks list

# 进入容器
ctr tasks exec --exec-id shell-1 my-nginx /bin/bash

# 删除容器
ctr tasks kill my-nginx
ctr containers delete my-nginx

# 使用不同命名空间
ctr -n k8s.io containers list    # Kubernetes 命名空间
ctr -n moby containers list       # Docker 命名空间

crictl（CRI 客户端）

crictl 通过 CRI 接口与 containerd 通信，与 Kubernetes 的交互方式一致：

# 配置 crictl
cat /etc/crictl.yaml
runtime-endpoint: unix:///run/containerd/containerd.sock
image-endpoint: unix:///run/containerd/containerd.sock

# 查看 Pod
crictl pods

# 查看容器
crictl ps
crictl ps -a                       # 包括已停止的

# 查看镜像
crictl images

# 查看容器日志
crictl logs <container-id>

# 进入容器
crictl exec -it <container-id> /bin/sh

# 查看容器详情
crictl inspect <container-id>

# 拉取镜像
crictl pull nginx:1.25

# 查看运行时信息
crictl info

nerdctl（Docker 兼容 CLI）

nerdctl 提供与 Docker CLI 几乎相同的用户体验：

# 与 docker 命令基本一致
nerdctl run -d --name web -p 8080:80 nginx:1.25
nerdctl ps
nerdctl logs web
nerdctl exec -it web /bin/bash
nerdctl stop web
nerdctl rm web

# 构建镜像（需要 BuildKit）
nerdctl build -t myapp:1.0 .

# Docker Compose 兼容
nerdctl compose up -d
nerdctl compose down

# 命名空间支持
nerdctl -n k8s.io ps              # 查看 K8s 容器

CLI 工具对比表

功能	ctr	crictl	nerdctl
定位	containerd 调试	K8s CRI 调试	Docker 替代品
Docker 兼容	否	部分	是
镜像构建	否	否	是（BuildKit）
Compose	否	否	是
网络管理	基础	否	是（CNI）
命名空间	支持	k8s.io 固定	支持
生产使用	调试用	K8s 排障	可用

镜像管理

containerd 的镜像管理基于内容寻址存储（Content-Addressable Storage）：

Snapshotter

Snapshotter 是 containerd 的文件系统层管理抽象，类似 Docker 的存储驱动：

Snapshotter	描述	适用场景
overlayfs	基于 OverlayFS（默认）	通用场景
native	基于普通目录拷贝	调试、NFS
devmapper	基于 Device Mapper	块存储性能
stargz	延迟拉取镜像	快速启动
nydus	按需加载镜像	大镜像快速启动

# /etc/containerd/config.toml
[plugins."io.containerd.grpc.v1.cri".containerd]
  snapshotter = "overlayfs"
  default_runtime_name = "runc"

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

CRI 集成

containerd 通过内置的 CRI 插件与 Kubernetes 集成：

Kubernetes 节点配置：

# kubelet 配置
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
containerRuntimeEndpoint: unix:///run/containerd/containerd.sock

与 Docker Engine 的对比

特性	Docker Engine	containerd
架构层级	dockerd -> containerd -> shim -> runc	containerd -> shim -> runc
镜像构建	内置	需要 BuildKit
CLI 体验	完善（docker CLI）	ctr/nerdctl
Compose	内置	nerdctl compose
网络	docker network	CNI 插件
CRI 支持	通过 dockershim（已移除）	原生 CRI 插件
资源占用	较高	较低
生产稳定性	成熟	成熟

总结

containerd 作为 Kubernetes 生态的标准容器运行时：

Kubernetes 1.24+ 必须使用 containerd 或 CRI-O，不再支持 Docker
使用 crictl 排查 Kubernetes 容器问题，它通过 CRI 接口交互
nerdctl 是 Docker CLI 的最佳替代，提供几乎完整的兼容性
配置 SystemdCgroup = true 与 kubelet 的 cgroup 驱动保持一致
考虑使用 stargz/nydus snapshotter 加速大镜像的启动
containerd 的命名空间机制 隔离了 Docker（moby）和 Kubernetes（k8s.io）的容器

贡献者

withesse

更新日志

2026/3/14 13:09

查看所有更新日志

9f6c2-feat: organize wiki content and refresh site setup于 2026/3/14