32、Docker运行时 VS Containerd运行时
约 5949 字大约 20 分钟
2025-09-04
一、架构层面深度对比
1.1 Docker 架构(传统模式)
┌─────────────────────────────────────────┐
│ Docker Client │
│ (docker CLI) │
└─────────────────┬───────────────────────┘
│ REST API
┌─────────────────▼───────────────────────┐
│ Docker Daemon (dockerd) │
│ ┌───────────────────────────────────┐ │
│ │ containerd (作为插件) │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ containerd-shim │ │ │
│ │ │ ┌─────────────────────┐ │ │ │
│ │ │ │ runc │ │ │ │
│ │ │ └─────────────────────┘ │ │ │
│ │ └─────────────────────────────┘ │ │
│ └───────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────┐ │
│ │ Docker 特有组件 │ │
│ │ • libnetwork (网络) │ │
│ │ • Swarmkit (编排) │ │
│ │ • BuildKit (构建) │ │
│ │ • 插件系统 │ │
│ │ • 镜像管理 │ │
│ └───────────────────────────────────┘ │
└─────────────────────────────────────────┘Docker:一体化容器平台,一个完整的容器化平台,提供从构建、分发到运行的全套工具链。
下面是docker提供的完整工具栈:
# Docker 提供的完整功能栈
功能层次:
应用层:
- Docker Compose: 多容器编排
- Docker Swarm: 集群管理
- Docker Desktop: 桌面环境
- Docker Hub: 镜像仓库
运行时层:
- 容器生命周期管理
- 网络管理 (libnetwork)
- 存储管理 (卷驱动)
- 日志和监控
构建层:
- Dockerfile 构建系统
- 镜像构建优化
- 多层缓存机制
安全层:
- 内容信任 (DCT)
- 安全扫描
- 访问控制docker :Monolithic Architecture(单体架构)
问题:
- 单点故障:一个组件崩溃影响整个系统
- 升级困难:需要升级整个 Docker 引擎
- 资源浪费:即使只用部分功能也要运行全部组件
- 安全性:攻击面大,权限过高
docekr的接口设计是RESTful API(面向用户)
- 人类可读(JSON over HTTP)
- 面向终端用户设计
- 包含高级抽象概念
- 包含业务逻辑
containerd的接口设计Containerd:gRPC API(面向系统)
- 强类型接口(.proto 文件定义)
- 二进制协议(高效)
- 流式传输支持
- 多语言支持
1.2 Containerd 架构(独立运行时)
┌─────────────────────────────────────────┐
│ 各种客户端工具 │
│ ┌────────┬───────┬────────┬────────┐ │
│ │docker │nerdctl│ ctr │kubelet │ │
│ │ CLI │ │ │ │ │
│ └────────┴───────┴────────┴────────┘ │
└─────────────────┬───────────────────────┘
│ gRPC API
┌─────────────────▼───────────────────────┐
│ containerd 守护进程 │
│ ┌───────────────────────────────────┐ │
│ │ Services │ │
│ │ • Containers (容器管理) │ │
│ │ • Images (镜像管理) │ │
│ │ • Tasks (任务管理) │ │
│ │ • Namespaces (命名空间) │ │
│ │ • Snapshots (快照) │ │
│ │ • Content (内容存储) │ │
│ │ • Events (事件) │ │
│ └───────────────────────────────────┘ │
│ │
│ ┌───────────────────────────────────┐ │
│ │ Plugins │ │
│ │ • Runtime (运行时插件) │ │
│ │ • Snapshotter(快照插件) │ │
│ │ • Diff (差异插件) │ │
│ │ • Monitoring(监控插件) │ │
│ │ • ... │ │
│ └───────────────────────────────────┘ │
└─────────────────┬───────────────────────┘
│
┌─────────────────▼───────────────────────┐
│ Runtimes │
│ ┌─────────┬────────┬────────┬──────┐ │
│ │ runc │ runsc │ kata │ ... │ │
│ │ (默认) │(gVisor)│(VM) │ │ │
│ └─────────┴────────┴────────┴──────┘ │
└─────────────────────────────────────────┘Containerd:专注的容器运行时,一个专注于容器生命周期的核心运行时,遵循 Unix 哲学中的"单一职责原则"。
containerd的核心职责:
# Containerd 的专注领域
核心职责:
容器管理:
- 创建/启动/停止/删除容器
- 容器状态管理
镜像管理:
- 拉取/推送 OCI 镜像
- 镜像存储管理
运行时接口:
- 提供标准的 CRI 接口
- 支持多种 OCI 运行时
插件架构:
- 快照器插件 (存储)
- 运行时插件 (执行)
- 内容插件 (镜像)Containerd:Microservices Architecture(微服务架构):
优势:
- 模块化:每个组件独立,可单独升级
- 可扩展:轻松添加新功能插件
- 高可用:组件故障不影响其他功能
- 安全性:最小权限原则,攻击面小
1.3、抽象层次的根本不同
Docker:高级抽象(用户友好)
┌─────────────────────────────────────────┐
│ User Experience Layer │ ← Docker 的重点
│ • Docker CLI (用户友好的命令) │
│ • Docker Compose (应用描述) │
│ • Dockerfile (构建描述) │
├─────────────────────────────────────────┤
│ Orchestration Layer │
│ • Docker Swarm (内置编排) │
│ • 服务发现、负载均衡 │
├─────────────────────────────────────────┤
│ Container Runtime Layer │
│ • containerd (内嵌) │ ← Containerd 的领域
│ • runc (实际执行) │
└─────────────────────────────────────────┘Docker 提供了哪些高级抽象:
- 网络抽象:
docker network create mynet,实际上做了:
- 创建网桥
- 配置 iptables
- 设置 DNS
- 配置路由
- 存储抽象
docker volume create myvol,实际上做了:
- 创建存储目录
- 设置权限
- 配置挂载点
- 服务抽象
docker service create --replicas 3 nginx实际上做了:
- 创建多个容器
- 配置负载均衡
- 健康检查
- 滚动更新
Containerd:低级抽象(系统友好)
┌─────────────────────────────────────────┐
│ System Integration Layer │ ← 系统集成的接口
│ • CRI (Kubernetes 接口) │
│ • OCI Runtime Spec │
│ • gRPC API │
├─────────────────────────────────────────┤
│ Container Core Layer │ ← Containerd 的核心
│ • 容器生命周期管理 │
│ • 镜像管理 │
│ • 命名空间管理 │
├─────────────────────────────────────────┤
│ Plugin Interface Layer │
│ • 运行时插件 (runc, gVisor, Kata) │
│ • 快照器插件 (overlayfs, devicemapper) │
│ • 内容插件 │
└─────────────────────────────────────────┘Containerd 的核心抽象:
- 容器抽象(最小化)容器定义:
- ID: 唯一标识符
- Image: OCI 镜像引用
- Spec: OCI 运行时规范
- SnapshotKey: 快照引用
- 任务抽象(执行单元)任务定义:
- ContainerID: 关联的容器
- Pid: 进程 ID
- Status: 运行状态
- Stdin/Stdout/Stderr: 标准流
- 快照抽象(存储)快照定义:
- Key: 快照键
- Parent: 父快照
- Kind: 快照类型(active, committed, view)
1.4、依赖关系的本质区别
Docker:垂直集成(全栈依赖)
Docker 的依赖链问题:
# 升级 Docker 时要考虑的所有依赖
升级 Docker 20.10 → 23.0 需要:
1. containerd: 1.4 → 1.6 ✓
2. runc: 1.0 → 1.1 ✓
3. libnetwork: ? → ? 可能不兼容
4. SwarmKit: ? → ? 可能不兼容
5. 插件系统: ? → ? 可能不兼容
6. BuildKit: ? → ? 可能不兼容
# 所有组件必须一起升级!Containerd:水平解耦(最小依赖)
Containerd 的依赖优势:
# 独立升级各组件
升级 containerd 1.6 → 1.7:
1. 停止 containerd 服务
2. 替换 containerd 二进制文件
3. 重启服务
4. 完成!
# 其他组件可以独立升级:
# - runc: 独立升级
# - CNI 插件: 独立升级
# - CSI 驱动: 独立升级
# - 监控插件: 独立升级二、核心组件详细对比
2.1 组件矩阵对比
| 组件 | Docker 运行时 | Containerd 运行时 | 差异说明 |
|---|---|---|---|
| 守护进程 | dockerd (Go) | containerd (Go) | Docker 更重量级 |
| API 协议 | REST API (HTTP/HTTPS) | gRPC API | gRPC 性能更好 |
| 客户端工具 | docker CLI | ctr, nerdctl | nerdctl 类似 Docker CLI |
| 容器运行时 | containerd (内嵌) | containerd (独立) | 相同技术栈 |
| 低级运行时 | runc (OCI) | runc (OCI) | 相同 |
| 网络管理 | libnetwork | CNI 插件 | Docker 网络更丰富 |
| 存储驱动 | 多种 (overlay2, devicemapper) | 插件式快照器 | 概念相似,实现不同 |
| 镜像格式 | Docker 镜像 | OCI 镜像 | 兼容但格式不同 |
2.2 网络栈对比
# Docker 网络(libnetwork)
# 提供完整的网络生态系统
docker network ls
# bridge, host, none, overlay (Swarm), macvlan, ipvlan
# Containerd 网络(CNI)
# 依赖外部 CNI 插件
nerdctl network ls
# 需要手动安装 CNI 插件,网络功能通过插件提供
# Docker 网络特性更丰富:
# 1. 内置的 overlay 网络(Swarm 模式)
# 2. 内置的 DNS 服务发现
# 3. 网络别名(--network-alias)
# 4. 更完善的网络隔离2.3 存储系统对比
# Docker 存储驱动
docker info | grep "Storage Driver"
# overlay2, aufs, devicemapper, btrfs, zfs
# Containerd 快照器
sudo ctr plugin ls | grep snapshotter
# overlayfs, native, devmapper, zfs, btrfs
# 关键差异:
# 1. Docker: 存储驱动 + 卷驱动
# 2. Containerd: 快照器插件 + 卷插件
# 3. Docker 的卷管理更成熟
# 4. Containerd 的插件架构更灵活三、性能对比分析
3.1 启动性能测试
# 测试脚本:比较容器启动时间
#!/bin/bash
echo "=== 容器启动性能测试 ==="
# 使用 Docker
echo "1. Docker 启动测试..."
time for i in {1..10}; do
docker run --rm alpine echo "Docker test $i" >/dev/null
done
# 使用 Containerd + nerdctl
echo -e "\n2. Containerd 启动测试..."
export CONTAINERD_NAMESPACE=moby
time for i in {1..10}; do
nerdctl run --rm alpine echo "Containerd test $i" >/dev/null
done
# 结果通常显示:
# Docker: 1.5-2.0秒/容器(包含完整栈)
# Containerd: 1.0-1.5秒/容器(更轻量)3.2 内存占用对比
bash
# 查看进程内存占用
ps aux | grep -E "(dockerd|containerd)" | grep -v grep
# 典型结果:
# Docker 架构:
# dockerd: ~150-300 MB
# containerd: ~50-100 MB(作为子进程)
# 总计:200-400 MB
# Containerd 独立架构:
# containerd: ~80-150 MB
# 总计:80-150 MB(节省 40-60% 内存)3.3 资源消耗矩阵
| 资源类型 | Docker | Containerd | 优势方 |
|---|---|---|---|
| 内存占用 | 200-400 MB | 80-150 MB | ✅ Containerd |
| CPU 使用 | 较高(多组件) | 较低(单一进程) | ✅ Containerd |
| 启动时间 | 较慢(完整栈) | 较快(轻量) | ✅ Containerd |
| 磁盘 I/O | 较高(多层抽象) | 较低(直接访问) | ✅ Containerd |
| 网络吞吐 | 优秀(优化多年) | 良好(依赖 CNI) | ⚠️ Docker 略优 |
四、功能特性详细对比
4.1 容器管理功能
# Docker 特有功能:
# 1. Docker Swarm 集群管理
docker swarm init
docker service create --replicas 3 nginx
# 2. Docker Compose 编排
docker-compose up -d
# 3. Docker Build(内置构建)
docker build -t myapp .
# 4. Docker 插件系统
docker plugin install vieux/sshfs
# 5. Docker 内容信任(DCT)
docker trust sign myimage:latest
# Containerd 缺失的功能:
# 1. 无内置集群编排
# 2. 无内置服务发现
# 3. 无内置镜像构建
# 4. 网络功能依赖 CNI
# 5. 无 GUI 管理工具4.2 镜像管理对比
# Docker 镜像管理(丰富)
功能:
- 镜像构建 (docker build)
- 镜像扫描 (docker scan)
- 镜像签名 (docker trust)
- 镜像保存/加载 (docker save/load)
- 镜像导入/导出 (docker import/export)
- 多架构镜像 (docker manifest)
- 镜像修剪 (docker image prune)
# Containerd 镜像管理(基础)
功能:
- 镜像拉取/推送 (ctr images pull/push)
- 镜像标签 (ctr images tag)
- 镜像删除 (ctr images rm)
- 镜像列表 (ctr images ls)
- OCI 镜像支持
# 需要外部工具完成高级功能4.3 安全特性对比
# Docker 安全特性:
# 1. AppArmor 配置文件
docker run --security-opt apparmor=docker-default
# 2. SELinux 标签
docker run --security-opt label=type:container_t
# 3. Seccomp 配置文件
docker run --security-opt seccomp=default.json
# 4. 用户命名空间
docker run --userns=host|remap
# 5. 内容信任
export DOCKER_CONTENT_TRUST=1
# Containerd 安全特性:
# 1. 支持所有 OCI 安全特性
# 2. 通过 CRI 插件支持 Pod 安全上下文
# 3. 支持用户命名空间(需要配置)
# 4. 支持 seccomp(需要配置文件)
# 5. 更细粒度的权限控制五、使用场景对比
5.1 适合 Docker 的场景
场景1: 开发和测试环境
原因:
- 完整的工具链
- Docker Compose 快速编排
- 丰富的社区镜像
- 易用的 GUI 工具 (Docker Desktop)
场景2: 单机部署
原因:
- 一站式解决方案
- 内置网络和存储
- 简单的监控和日志
- 成熟的生态系统
场景3: 传统应用迁移
原因:
- 兼容性好
- 迁移工具丰富
- 企业级支持
- 完善的文档
场景4: 中小型企业
原因:
- 管理简单
- 学习成本低
- 社区支持好
- 成本可控5.2 适合 Containerd 的场景
场景1: Kubernetes 生产环境
原因:
- Kubernetes 官方推荐
- 性能更好
- 资源占用少
- 稳定性更高
场景2: 大规模容器部署
原因:
- 轻量级设计
- 可扩展性好
- 与云原生生态集成
- 更适合自动化
场景3: 嵌入式/IoT 设备
原因:
- 资源占用极小
- 可定制性强
- 启动速度快
- 适合资源受限环境
场景4: 需要多运行时环境
原因:
- 插件化架构
- 支持 runc, gVisor, Kata 等
- 灵活的运行时选择
- 安全沙箱需求六、配置和管理对比
6.1 配置文件对比
# Docker 配置 (/etc/docker/daemon.json)
{
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m",
"max-file": "3"
},
"storage-driver": "overlay2",
"storage-opts": [
"overlay2.override_kernel_check=true"
],
"live-restore": true,
"default-ulimits": {
"nofile": {
"name": "nofile",
"hard": 65536,
"soft": 65536
}
},
"registry-mirrors": [
"https://docker.mirrors.ustc.edu.cn"
]
}
# Containerd 配置 (/etc/containerd/config.toml)
version = 2
root = "/var/lib/containerd"
state = "/run/containerd"
[plugins]
[plugins."io.containerd.grpc.v1.cri"]
sandbox_image = "registry.k8s.io/pause:3.9"
[plugins."io.containerd.grpc.v1.cri".containerd]
default_runtime_name = "runc"
snapshotter = "overlayfs"
[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
[plugins."io.containerd.grpc.v1.cri".registry]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors]
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
endpoint = ["https://registry-1.docker.io"]6.2 监控和日志对比
# Docker 监控(内置丰富)
docker stats # 实时资源监控
docker events # 容器事件
docker logs # 容器日志
docker inspect # 容器详情
docker top # 容器进程
# 第三方集成:
# - cAdvisor
# - Prometheus (docker_exporter)
# - ELK Stack
# Containerd 监控(需要工具)
# 1. 内置 metrics 端点
curl http://localhost:1338/metrics
# 2. 使用 ctr 查看
sudo ctr containers list
sudo ctr tasks list
# 3. 使用 nerdctl(类似 Docker)
nerdctl stats
nerdctl logs
# 4. CRI 工具
crictl ps
crictl logs
# 5. 需要更多第三方工具集成6.3 备份和迁移
# Docker 备份(工具丰富)
# 容器备份
docker export -o container.tar mycontainer
docker import container.tar myimage:backup
# 卷备份
docker run --rm -v myvolume:/data -v $(pwd):/backup \
alpine tar czf /backup/myvolume.tar.gz -C /data .
# 完整备份
docker save -o all-images.tar $(docker images -q)
# Containerd 备份(更底层)
# 镜像备份
sudo ctr images export images.tar docker.io/library/nginx:latest
# 容器检查点(实验性)
sudo ctr checkpoint create mycontainer checkpoint1
# 需要手动备份目录:
# /var/lib/containerd/
# /etc/containerd/
# /run/containerd/七、生态系统和兼容性
7.1 工具链兼容性
# 兼容 Docker 的工具:
- Docker Compose: ✅ 完全兼容(通过 docker.sock)
- Portainer: ✅ 完全兼容
- Rancher: ✅ 完全兼容
- Traefik: ✅ 完全兼容
- Jenkins: ✅ 完全兼容
- GitLab CI: ✅ 完全兼容
- 大多数 DevOps 工具
# 需要适配的工具:
- 某些监控工具:需要调整配置
- 网络工具:从 libnetwork 切换到 CNI
- 存储工具:从 volume driver 切换到 CSI
- 安全工具:可能需要调整策略
Docker:终端用户产品,更多是面向开发,运维人员:
Docker 的定位:
目标用户: 开发者和运维人员
使用场景:
- 本地开发环境
- CI/CD 流水线
- 小型部署
- 原型验证
商业模式:
- Docker Desktop (商业版)
- Docker Hub (高级功能)
- 企业支持
生态系统:
- 围绕 Docker 构建的工具链
- Docker Certified 认证
- 培训和教育资源7.2 Kubernetes 集成
# Docker 作为 Kubernetes 运行时(已弃用)
# Kubernetes 1.20 之前:
# kubelet → dockershim → dockerd → containerd → runc
# 问题:多层抽象,性能损失,维护复杂
# Containerd 作为 Kubernetes 运行时(推荐)
# Kubernetes 1.20+:
# kubelet → CRI plugin → containerd → runc
# 优势:更简单,更高效,更稳定
# 检查 Kubernetes 节点运行时
kubectl get nodes -o wide
kubectl describe node <node-name> | grep -i runtime
# 期望输出:containerRuntimeVersion: containerd://1.6.8
Containerd:基础设施组件;
Containerd 的定位:
目标用户: 系统集成商和平台开发者
使用场景:
- Kubernetes 运行时
- 云平台基础设施
- 容器即服务 (CaaS)
- 边缘计算平台
商业模式:
- CNCF 托管项目 (开源)
- 社区驱动
- 厂商支持 (通过发行版)
生态系统:
- 云原生计算基金会 (CNCF) 项目
- 与 Kubernetes 深度集成
- 作为其他平台的基础组件7.3 社区和支持
| 方面 | Docker | Containerd |
|---|---|---|
| 公司支持 | Docker Inc. (Mirantis) | CNCF (云原生基金会) |
| 开源协议 | Apache 2.0 | Apache 2.0 |
| 社区活跃度 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 文档质量 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| 学习资源 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| 企业采用 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐(增长中) |
| 云厂商支持 | 所有主要云厂商 | 所有主要云厂商 |
八、迁移方案和挑战
8.1 从 Docker 迁移到 Containerd
#!/bin/bash
# migrate-docker-to-containerd.sh
echo "=== Docker 到 Containerd 迁移指南 ==="
# 步骤1:备份 Docker 数据
echo "1. 备份 Docker 数据..."
docker save $(docker images -q) -o docker-images-backup.tar
docker ps -a --format json > docker-containers.json
# 步骤2:安装 containerd
echo "2. 安装 containerd..."
sudo apt-get update
sudo apt-get install -y containerd
# 步骤3:配置 containerd
echo "3. 配置 containerd..."
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
# 步骤4:停止 Docker,启动 containerd
echo "4. 切换服务..."
sudo systemctl stop docker
sudo systemctl disable docker
sudo systemctl enable containerd
sudo systemctl start containerd
# 步骤5:安装 nerdctl(Docker 兼容工具)
echo "5. 安装 nerdctl..."
wget https://github.com/containerd/nerdctl/releases/latest/download/nerdctl-full-linux-amd64.tar.gz
sudo tar Cxzvf /usr/local nerdctl-full-linux-amd64.tar.gz
# 步骤6:导入 Docker 镜像
echo "6. 导入镜像..."
nerdctl load -i docker-images-backup.tar
# 步骤7:重新创建容器
echo "7. 重新创建容器(根据备份)..."
# 需要根据 docker-containers.json 重新创建
echo "迁移完成!使用 'nerdctl' 替代 'docker' 命令"8.2 迁移挑战和解决方案
挑战1: 网络配置差异
Docker: 使用 libnetwork,配置在 docker-compose.yml 或命令行
Containerd: 使用 CNI,需要单独的配置文件
解决方案:
- 将 Docker 网络配置转换为 CNI 配置
- 使用 nerdctl network create 重新创建
- 对于复杂网络,可能需要调整应用配置
挑战2: 存储卷迁移
Docker: 使用 volume driver
Containerd: 使用 CSI 或本地卷
解决方案:
- 备份 Docker 卷数据
- 重新挂载到 containerd 容器
- 对于有状态应用,需要确保数据一致性
挑战3: Docker 特有功能
Docker Swarm、Docker Content Trust、Docker Build
解决方案:
- Swarm: 迁移到 Kubernetes 或其他编排工具
- DCT: 使用其他镜像签名方案(如 Notary)
- Docker Build: 使用 BuildKit 独立版本或 kaniko
挑战4: 工具链适配
许多工具直接调用 Docker API
解决方案:
- 使用 Docker API 兼容层(如 cri-dockerd)
- 更新工具使用 CRI 接口
- 使用 nerdctl 作为替代九、未来发展趋势
9.1 技术演进方向
Docker 的未来:
- 专注于开发者体验
- Docker Desktop 商业化
- 简化开发工作流
- 云原生工具集成
- 安全增强功能
Containerd 的未来:
- 成为容器运行时标准
- 更好的 Kubernetes 集成
- 性能优化
- 安全沙箱增强
- 边缘计算支持
共同趋势:
- 标准化(OCI 标准)
- 安全性提升
- 性能优化
- 多架构支持(ARM、RISC-V)
- WebAssembly 集成9.2 行业采用情况
# 2023年容器运行时调查
# 来源:CNCF 年度调查
使用比例:
- Docker: 79% (开发环境), 35% (生产环境)
- Containerd: 46% (生产环境), 快速增长中
- CRI-O: 28% (生产环境)
- 其他: 7%
# 趋势分析:
# 1. 开发环境:Docker 仍占主导(易用性)
# 2. 生产环境:Containerd 快速增长(性能、稳定性)
# 3. Kubernetes 默认转向 Containerd
# 4. 边缘/IoT:Containerd 更受欢迎(轻量)十、总结和建议
10.1 对比总结表
| 维度 | Docker | Containerd | 建议 |
|---|---|---|---|
| 架构复杂度 | 高(多组件) | 低(单一进程) | ✅ Containerd |
| 性能 | 良好 | 优秀 | ✅ Containerd |
| 资源占用 | 较高 | 较低 | ✅ Containerd |
| 功能完整性 | 完整 | 基础(需插件) | ✅ Docker |
| 易用性 | 优秀 | 一般(需学习) | ✅ Docker |
| K8s 集成 | 已弃用 | 官方推荐 | ✅ Containerd |
| 生产就绪 | 优秀 | 优秀 | ✅ 两者均可 |
| 未来发展 | 开发者导向 | 云原生标准 | ⚖️ 根据需求 |
10.2 选择建议
选择 Docker 当:
- 你是初学者或小型团队
- 需要完整的开箱即用体验
- 使用 Docker Compose 进行本地开发
- 不需要 Kubernetes 或使用旧版本
- 依赖 Docker 特有功能(如 Swarm)
- 开发环境或测试环境选择 Containerd 当:
- 你使用 Kubernetes(1.20+)
- 需要最高性能和最低资源占用
- 大规模生产部署
- 嵌入式或资源受限环境
- 需要多运行时支持(安全沙箱)
- 追求云原生技术栈混合使用方案:
# 开发环境用 Docker,生产环境用 Containerd
# 这是很多企业的实际选择
开发环境:
Docker Desktop (Mac/Windows)
或 Docker Engine (Linux)
理由: 工具丰富,调试方便,社区支持好
生产环境:
Containerd + Kubernetes
理由: 性能好,稳定性高,云原生兼容
CI/CD 环境:
根据需求选择,通常与生产环境一致10.3 最终建议
- 新项目:直接使用 Containerd,特别是如果计划使用 Kubernetes
- 现有 Docker 项目:评估迁移成本,逐步迁移
- 开发环境:可以继续使用 Docker,享受其易用性
- 生产环境:强烈建议迁移到 Containerd,特别是 Kubernetes 环境
- 学习路径:先学 Docker(理解概念),再学 Containerd(深入原理)
Docker 和 Containerd 不是简单的"替代"关系,而是不同抽象层次、不同目标用户、不同设计理念的技术产品。
10.4、小结
Docker:是一个完整的容器化应用平台,旨在为开发者提供端到端的容器解决方案
Containerd:是一个专注于容器生命周期的核心运行时,旨在为系统集成提供稳定可靠的基础组件
| 维度 | Docker | Containerd | 本质区别 |
|---|---|---|---|
| 设计目标 | 简化开发者体验 | 提供稳定运行时 | 用户 vs 系统 |
| 架构风格 | 单体架构 | 微服务架构 | 一体 vs 模块 |
| API 设计 | RESTful(面向人) | gRPC(面向机器) | 易用 vs 高效 |
| 抽象层次 | 高级抽象(用户友好) | 低级抽象(系统友好) | 产品 vs 组件 |
| 依赖关系 | 垂直集成(全栈) | 水平解耦(最小) | 耦合 vs 解耦 |
| 扩展方式 | 有限插件系统 | 开放式插件架构 | 封闭 vs 开放 |
| 安全模型 | 粗粒度(单一边界) | 细粒度(多层边界) | 简单 vs 纵深 |
| 升级策略 | 整体升级 | 独立升级 | 笨重 vs 灵活 |
| 生态系统 | 终端产品生态 | 基础设施生态 | 应用层 vs 系统层 |
| 商业模式 | 商业产品 | 开源基础设施 | 商业 vs 社区 |
用户运行一个docker容器,发生了什么
我们首先来看一下docker的整体架构,然后在从架构层面了解下,当用户执行一个docker run命令后,docker实际帮助我们做了哪些工作:
┌─────────────────────────────────┐
│ Docker Platform │ 面向终端用户
│ • docker CLI (用户界面) │
│ • Docker Daemon (服务层) │
│ • 网络/存储/构建等高级功能 │
├─────────────────────────────────┤
│ containerd │ 面向底层基础设施
│ • 容器生命周期管理 │
│ • 镜像管理 │
│ • 任务管理 │
├─────────────────────────────────┤
│ runc │
│ • 实际容器执行 │
│ • OCI 规范实现 │
└─────────────────────────────────┘当用户执行docker run -d --name web -p 80:80 nginx:alpine命令后,docker帮助我们做了以下工作:
- docker CLI: 接收用户命令,格式化请求
- dockerd: docker守护进程
- 检查本地是否有 nginx:alpine 镜像
- 如果没有,从 Docker Hub 拉取
- 创建网络配置(端口映射 80:80)
- 准备存储卷(如果需要)
- 生成 OCI 运行时规范
- 调用 containerd API 创建容器
- containerd 调用 runc 实际启动容器
docker和containerd 功能职责划分:
| 功能 | Docker 封装层 | Containerd 运行时 | docker具体抽象 |
|---|---|---|---|
| 用户命令 | docker run | ❌ 不提供 | ✅ Docker 封装 |
| 镜像构建 | Dockerfile 构建 | ❌ 不提供 | ✅ Docker 封装 |
| 网络管理 | libnetwork, port mapping | ❌ 基础网络 | ✅ Docker 封装 |
| 存储管理 | 卷驱动, bind mount | ❌ 快照器 | ✅ Docker 封装 |
| 容器创建 | 调用 containerd API | ✅ 实际创建 | ✅ containerd运行时 |
| 容器启动 | 调用 containerd API | ✅ 实际启动 | ✅ containerd运行时 |
| 镜像拉取 | 调用 containerd API | ✅ 实际拉取 | ✅ 底层运行时 |
containerd: 是"容器运行时引擎"
- 负责: 容器生命周期管理
- 特点: 专注、高效、稳定
- 用户: 系统集成者、Kubernetes
Docker: 是"容器应用平台"
- 包含: containerd 作为运行时
- 增加: 用户友好的封装层
- 提供: 开发到部署的完整工具链
- 用户: 开发者、运维人员
关键洞察:
- 不是"Docker vs containerd"
- 而是"Docker 包含 containerd"
- Docker = containerd + 用户友好的封装
- 就像: Chrome = Blink 引擎 + 用户界面
底层运行时(Low-Level Runtimes)
负责直接与操作系统交互,创建和管理容器进程(设置命名空间、cgroups、文件系统等)。
- runc
- 最常用的底层运行时,基于 OCI(Open Container Initiative)标准实现。
- 被 Docker、containerd 等默认使用。
- 轻量级,但功能相对基础(仅负责容器生命周期管理)。
- crun
- 用 C 语言编写的 OCI 运行时,性能优于 runc(资源占用更低)。
- 支持 Linux 和部分 Unix 系统,常用于资源敏感场景。
- railcar
- Rust 语言实现的 OCI 运行时(已归档,不再活跃)。
- youki
- 用 Rust 编写的 OCI 运行时,由 Kubernetes 社区推动。
- 注重安全性和性能,兼容 runc 功能。
- Kata Containers
- 安全容器运行时,每个容器运行在独立的轻量级虚拟机中(基于硬件虚拟化隔离)。
- 适用于多租户强隔离场景(如公有云、不可信工作负载)。
- gVisor
- 谷歌开发的沙箱容器运行时,通过用户空间内核拦截系统调用,提供安全隔离。
- 性能开销低于虚拟机,但强于命名空间隔离。
- Firecracker
- AWS 开发的轻量级虚拟机管理器(MicroVM),用于安全容器(如 AWS Lambda、Fargate)。
- 专注于极简和快速启动,结合虚拟化安全与容器效率。
- Nabla Containers
- 基于 Unikernel 理念的隔离容器,通过减少系统调用界面提升安全性。
贡献者
版权所有
版权归属:codingLab
许可证:bugcode