云原生技术02-containerd、CRI-O、Podman：2026年容器runtime怎么选？

目录

• 开篇：Docker怎么了？
• 一、Docker的"中年危机"
• 二、containerd：Docker的"瘦身版替身"
• 三、CRI-O：K8s的"亲儿子"
• 四、Kata Containers：安全与性能的"平衡术"
• 五、gVisor：沙箱界的"保守派"
• 六、2026年容器runtime选型指南
• 文末三件套

开篇：Docker怎么了？

你是否遇到过Docker守护进程内存占用越来越高、启动速度越来越慢、生产环境想换掉Docker又不知道换什么的困境？容器runtime世界早已天翻地覆，本文将告诉你2026年容器运行时的正确打开方式。

💡效率技巧：如果你还在用Docker直接跑生产环境，可能已经落后了两个大版本。这不是危言耸听，是血淋淋的事实。

一、Docker的"中年危机"

1.1 守护进程模式：那个不肯退休的"老管家"

Docker的设计哲学很简单：一个守护进程（dockerd）管理一切。这在2013年是个天才设计，但在2026年，这就像让一位老管家同时负责买菜、做饭、打扫、看门——还兼任保安队长。

┌─────────────────────────────────────────────────────────┐ │ Docker 架构（传统） │ ├─────────────────────────────────────────────────────────┤ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ docker │ │ docker │ │ docker │ CLI 工具 │ │ │ build │ │ run │ │ push │ │ │ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ │ │ │ │ └──────────────┼──────────────┘ │ │ ▼ │ │ ┌─────────────┐ │ │ │ dockerd │ ← 200MB+ 内存占用 │ │ │ (守护进程) │ │ │ └──────┬──────┘ │ │ │ │ │ ┌─────────────┼─────────────┐ │ │ ▼ ▼ ▼ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │container│ │ image │ │ network │ │ │ │ runtime │ │ store │ │ mgmt │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ 臃肿! │ │ ▼ │ │ ┌─────────┐ │ │ │ runc │ ← 真正的容器运行时 │ │ └─────────┘ │ └─────────────────────────────────────────────────────────┘

问题在哪？

1. 单点故障：dockerd挂了，所有容器都受影响
2. 资源黑洞：守护进程常驻内存，空载也要200MB+
3. 启动延迟：每次操作都要和守护进程通信，多了层IPC开销

⚠️避坑警告：生产环境用Docker时，务必设置--live-restore参数。否则dockerd重启时，所有容器都会跟着重启——这在高并发场景下就是灾难。

1.2 内存占用：那个越来越胖的"管家"

让我们看一组对比数据：

💡效率技巧：containerd的内存占用只有Docker的1/13，这意味着在同样配置的机器上，你能多跑几十个容器实例。

1.3 启动速度：慢半拍的"老司机"

Docker的启动流程是这样的：

用户命令 → docker CLI → dockerd（守护进程）→ containerd → runc → 容器启动

每一层都是一次进程间通信（IPC），都是一次上下文切换。在微服务架构下，这种延迟会被放大几百倍。

二、containerd：Docker的"瘦身版替身"

2.1 什么是containerd？

containerd是Docker公司"自废武功"的产物。2016年，Docker把容器运行时核心抽离出来，捐给了CNCF。这不是慈善，是自救。

┌─────────────────────────────────────────────────────────┐ │ containerd 架构 │ ├─────────────────────────────────────────────────────────┤ │ │ │ ┌─────────┐ ┌─────────────┐ │ │ │ Client │──────▶│ containerd │ ← 15MB 内存 │ │ │ (ctr) │ │ (gRPC) │ │ │ └─────────┘ └──────┬──────┘ │ │ │ │ │ ┌──────────────────┼──────────────────┐ │ │ ▼ ▼ ▼ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ Image │ │Runtime │ │ Task │ │ │ │ Service │ │ Service │ │ Service │ │ │ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ 镜像存储 │ │ runc │ │ 容器进程 │ │ │ │ (快照) │ │(OCI运行时)│ │ 管理 │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ 简洁、高效、专注做一件事：运行容器 │ └─────────────────────────────────────────────────────────┘

2.2 为什么选containerd？

优势一览：

1. 轻量级：守护进程仅15MB内存占用
2. 标准化：完全兼容OCI（Open Container Initiative）标准
3. 高性能：直接对接runc，减少中间层
4. 云原生：Kubernetes默认支持，无需额外适配

2.3 实操：用containerd运行容器

# 安装containerd sudo apt-get install containerd # 启动服务 sudo systemctl start containerd # 拉取镜像（使用ctr命令行工具） sudo ctr images pull docker.io/library/nginx:latest # 运行容器 sudo ctr run --rm -t docker.io/library/nginx:latest webserver # 查看运行中的容器 sudo ctr containers list # 查看任务（进程） sudo ctr tasks list

💡效率技巧：containerd的ctr命令比Docker CLI简陋很多，这是设计上的取舍——专业的事交给专业工具。如果你需要完整的CLI体验，可以用nerdctl，它是Docker CLI的containerd兼容版本。

2.4 安装nerdctl（可选但推荐）

# 下载nerdctl wget https://github.com/containerd/nerdctl/releases/download/v1.7.0/nerdctl-1.7.0-linux-amd64.tar.gz # 解压 sudo tar Cxzvf /usr/local/bin nerdctl-1.7.0-linux-amd64.tar.gz # 现在你可以用熟悉的Docker命令了 nerdctl run -d -p 80:80 --name mynginx nginx:latest nerdctl ps nerdctl exec -it mynginx bash

三、CRI-O：K8s的"亲儿子"

3.1 什么是CRI-O？

CRI-O是Kubernetes的专用容器运行时。它的诞生有一个很直接的原因：Kubernetes不需要Docker那么多功能。

┌─────────────────────────────────────────────────────────┐ │ CRI-O 架构 │ ├─────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────┐ │ │ │ Kubernetes │ │ │ │ (kubelet) │ │ │ └────────┬────────┘ │ │ │ CRI (Container Runtime Interface) │ │ ▼ │ │ ┌─────────────────┐ ┌─────────────┐ │ │ │ CRI-O │────▶│ conmon │ ← 容器监控 │ │ │ (轻量级守护) │ │ (轻量级) │ │ │ └────────┬────────┘ └─────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────┐ ┌─────────────┐ │ │ │ OCI Runtime │────▶│ runc │ │ │ │ (可插拔) │ │ (默认) │ │ │ └─────────────────┘ └─────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────┐ ┌─────────────┐ │ │ │ Kata Containers│ │ gVisor │ ← 可选安全运行时│ │ │ (可选) │ │ (可选) │ │ │ └─────────────────┘ └─────────────┘ │ │ │ │ 专注K8s，别无旁骛 │ └─────────────────────────────────────────────────────────┘

3.2 CRI-O vs containerd：选哪个？

⚠️避坑警告：如果你同时需要Kubernetes和独立的容器管理（比如开发环境），containerd是更好的选择。CRI-O真的只适合"纯K8s"场景。

3.3 实操：CRI-O + Kubernetes

# 安装CRI-O（以Ubuntu为例） OS=xUbuntu_22.04 CRIO_VERSION=1.28 echo "deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/ /" | \ sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list echo "deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$CRIO_VERSION/$OS/ /" | \ sudo tee /etc/apt/sources.list.d/devel:kubic:libcontainers:stable:cri-o:$CRIO_VERSION.list curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$CRIO_VERSION/$OS/Release.key | sudo apt-key add - curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key add - sudo apt-get update sudo apt-get install cri-o cri-o-runc # 启动CRI-O sudo systemctl start crio # 配置kubelet使用CRI-O cat <<EOF | sudo tee /etc/default/kubelet KUBELET_EXTRA_ARGS=--container-runtime=remote --container-runtime-endpoint=unix:///var/run/crio/crio.sock EOF # 重启kubelet sudo systemctl restart kubelet

四、Kata Containers：安全与性能的"平衡术"

4.1 什么是Kata Containers？

Kata Containers把虚拟机的安全性和容器的速度结合起来。每个容器跑在一个轻量级VM里，实现了真正的内核隔离。

┌─────────────────────────────────────────────────────────┐ │ Kata Containers 架构 │ ├─────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────────────────────────────────────┐ │ │ │ Host Kernel │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ │ │ Kata │ │ Kata │ │ Kata │ │ │ │ │ │Runtime │ │Runtime │ │Runtime │ │ │ │ │ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ │ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ │ │轻量级VM │ │轻量级VM │ │轻量级VM │ │ │ │ │ │(Guest) │ │(Guest) │ │(Guest) │ │ │ │ │ │内核隔离 │ │内核隔离 │ │内核隔离 │ │ │ │ │ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ │ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ │ │Container│ │Container│ │Container│ │ │ │ │ │ App A │ │ App B │ │ App C │ │ │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ │ │ │ │ 每个容器一个VM = 真正的内核隔离 │ │ │ └─────────────────────────────────────────────────┘ │ │ │ │ 对比传统容器： │ │ ┌─────────────────────────────────────────────────┐ │ │ │ Host Kernel (共享) │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ │ │Container│ │Container│ │Container│ │ │ │ │ │ App A │ │ App B │ │ App C │ │ │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ 共享内核 = 潜在的安全风险 │ │ │ └─────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────┘

4.2 性能对比

💡效率技巧：Kata Containers的硬件虚拟化隔离，开销比gVisor低30%。如果你的workload对性能敏感但又需要强隔离，Kata是更好的选择。

4.3 实操：Kata Containers + containerd

# 安装Kata Containers sudo apt-get install kata-containers # 配置containerd使用Kata sudo mkdir -p /etc/containerd/ containerd config default | sudo tee /etc/containerd/config.toml # 编辑配置，添加Kata runtime sudo tee -a /etc/containerd/config.toml <<EOF [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata] runtime_type = "io.containerd.kata.v2" EOF # 重启containerd sudo systemctl restart containerd # 使用Kata运行容器 sudo ctr run --rm --runtime io.containerd.run.kata.v2 -t docker.io/library/nginx:latest kata-nginx # 查看VM信息 sudo kata-runtime list

五、gVisor：沙箱界的"保守派"

5.1 什么是gVisor？

gVisor是Google开源的用户态内核，用Go语言实现了一个"沙箱内核"。它拦截所有系统调用，在应用和真实内核之间加了一道防火墙。

┌─────────────────────────────────────────────────────────┐ │ gVisor 架构 │ ├─────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────────────────────────────────────┐ │ │ │ Host Kernel │ │ │ │ ┌─────────────────────────────────────────┐ │ │ │ │ │ gVisor (Sentry) │ │ │ │ │ │ 用户态内核（Go实现） │ │ │ │ │ │ │ │ │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ │ │ │ │ 沙箱 A │ │ 沙箱 B │ │ 沙箱 C │ │ │ │ │ │ │ │(独立内核)│ │(独立内核)│ │(独立内核)│ │ │ │ │ │ │ └────┬────┘ └────┬────┘ └────┬────┘ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │ │ │ │ │ │Container│ │Container│ │Container│ │ │ │ │ │ │ │ App A │ │ App B │ │ App C │ │ │ │ │ │ │ └─────────┘ └─────────┘ └─────────┘ │ │ │ │ │ │ │ │ │ │ │ │ 所有系统调用被拦截、过滤、重实现 │ │ │ │ │ └─────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────┘ │ │ │ │ 安全级别：极高（但性能开销也大） │ └─────────────────────────────────────────────────────────┘

5.2 gVisor的优缺点

优点：

• 安全性极高（系统调用完全隔离）
• 无需硬件虚拟化支持
• 适合运行不可信代码

缺点：

• 性能开销大（系统调用需要两次上下文切换）
• 兼容性有限（部分系统调用未完全实现）
• 内存占用高

⚠️避坑警告：gVisor不适合IO密集型应用。数据库、文件服务器这类workload在gVisor里性能会下降30%-50%。

5.3 实操：gVisor + Docker

# 安装gVisor ( set -e ARCH=$(uname -m) URL=https://storage.googleapis.com/gvisor/releases/release/latest wget ${URL}/${ARCH}/runsc ${URL}/${ARCH}/runsc.sha512 sha512sum -c runsc.sha512 chmod a+rx runsc sudo mv runsc /usr/local/bin ) # 配置Docker使用gVisor cat <<EOF | sudo tee /etc/docker/daemon.json { "runtimes": { "runsc": { "path": "/usr/local/bin/runsc" } } } EOF # 重启Docker sudo systemctl restart docker # 使用gVisor运行容器 docker run --runtime=runsc -it ubuntu dmesg # 查看gVisor日志 sudo runsc --debug-log=/tmp/runsc/ do echo "Hello gVisor"

六、2026年容器runtime选型指南

6.1 决策树

┌─────────────────┐ │ 你的场景是什么？ │ └────────┬────────┘ │ ┌──────────────────┼──────────────────┐ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ 纯K8s │ │ 混合环境 │ │ 高安全 │ │ 生产环境 │ │ 开发+生产 │ │ 需求 │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ CRI-O │ │containerd│ │ Kata/ │ │ │ │ │ │ gVisor │ └──────────┘ └──────────┘ └──────────┘ │ │ │ ▼ ▼ ▼ 最轻量、最专注 最通用、最灵活 Kata: 性能+安全 gVisor: 最高安全

6.2 选型建议

6.3 迁移路径

如果你现在用Docker，迁移到containerd其实很简单：

# 1. 导出Docker镜像 docker save myapp:latest > myapp.tar # 2. 导入containerd sudo ctr images import myapp.tar # 3. 运行 sudo ctr run --rm -t docker.io/library/myapp:latest myapp # 或者用nerdctl（体验完全一致） nerdctl load -i myapp.tar nerdctl run -d --name myapp myapp:latest

文末三件套

1. 【源码获取】

关注此系列获取后续更新，后台回复’容器’获取链接。

2. 【思考题】

你的容器runtime选的是什么？为什么选它？

• 是追求极致轻量的CRI-O？
• 是生态最好的containerd？
• 还是安全至上的Kata/gVisor？

欢迎在评论区分享你的选择和使用体验。

3. 【系列预告】

本系列后续文章：

• K8s核心架构：从etcd到kubelet，彻底搞懂Kubernetes
• CNI网络：Flannel、Calico、Cilium怎么选？
• 存储：PV、PVC、StorageClass，容器存储的正确姿势

附录：参考资源

• containerd官方文档
• CRI-O GitHub
• Kata Containers官网
• gVisor文档
• OCI Runtime Spec

标签：Docker, containerd, CRI-O, KataContainers, gVisor, 容器runtime, OCI