583 字
2 分钟
为什么 Kubernetes 要替换 Docker
2020 年，Kubernetes 宣布弃用 Docker（Dockershim）。这一决定在社区引起轩然大波。为什么 Kubernetes 要替换 Docker？Docker 做错了什么？
一、Kubernetes 与 Docker 的关系
1.1 早期的甜蜜时光
flowchart LR
subgraph Kubernetes
K[API Server]
K --> CM[Container Manager]
end
subgraph Docker
D[Docker Daemon]
D --> R[Runtime]
end
K --> D
早期 Kubernetes 直接与 Docker 交互，使用 Docker 作为容器运行时。
1.2 问题的根源
flowchart TB
K[Kubernetes] --> D[Docker]
subgraph Docker 的问题
N[非标准的容器接口]
M[维护负担重]
F[功能膨胀]
end
K --> N
K --> M
K --> F
二、为什么 Kubernetes 放弃 Docker？
2.1 Docker 不是标准的容器运行时
flowchart LR
subgraph OCI (Open Container Initiative)
R[Runtime Spec]
I[Image Spec]
end
subgraph Docker
D[Docker]
end
subgraph containerd
C[containerd]
end
Note: Docker 实现了自己的 API，不完全兼容 OCI
Note: containerd 是 OCI 兼容的
OCI 标准：
- Runtime Spec：容器运行规范
- Image Spec：镜像规范
2.2 Docker 过于臃肿
| 组件 | Docker 包含 | Kubernetes 实际需要 |
|---|---|---|
| Docker Daemon | 是 | 否 |
| Docker CLI | 是 | 否 |
| containerd | 是 | 是 |
| runc | 是 | 是 |
| docker-init | 是 | 否 |
| 网络插件 | 是 | 否 |
Docker 不是为 Kubernetes 设计的，Kubernetes 只需要 containerd 和 runc。
2.3 维护负担
flowchart LR
K[Kubernetes] --> D[Docker]
K --> D2[containerd]
Note over D: Kubernetes 需要维护与 Docker 的兼容性代码
Note over D2: containerd 更简单，维护负担更轻
维护 Dockershim 代码给 Kubernetes 团队带来额外负担。
三、容器运行时的演进
3.1 CRI（Container Runtime Interface）
Kubernetes 定义了 CRI 接口：
flowchart TB
K[Kubernetes] --> CRI[CRI API]
CRI --> D[Docker (通过 shim)]
CRI --> C[containerd]
CRI --> R[CRI-O]
CRI --> F[Frakti]
3.2 各运行时的角色
| 运行时 | 说明 |
|---|---|
| Docker | 完整的开发平台，包含构建、运行、镜像管理 |
| containerd | 仅负责容器运行，是 Docker 的一部分 |
| runc | OCI 标准的参考实现，容器启动工具 |
| CRI-O | 仅实现 CRI，专为 Kubernetes 设计 |
3.3 从 Docker 到 containerd
sequenceDiagram
participant K as Kubernetes
participant D as Docker Daemon
participant C as containerd
participant R as runc
rect rgb(200, 230, 200)
Note over K,D: 过去：Kubernetes → Docker → containerd → runc
K->>D: API 调用
D->>C: 调用
C->>R: 启动容器
end
rect rgb(200, 200, 230)
Note over K,R: 现在：Kubernetes → containerd → runc
K->>C: CRI 调用
C->>R: 启动容器
end
四、Docker 的历史贡献
4.1 Docker 的伟大创新
mindmap
root((Docker 的贡献))
容器技术普及
让容器技术流行
降低了使用门槛
镜像格式标准化
layer 概念
Dockerfile
生态系统
Docker Hub
docker-compose
Docker 的贡献：
- 普及了容器技术
- 推动了云原生的发展
- 建立了镜像格式的事实标准
4.2 Docker 仍然有价值
# Docker 仍然是最好的容器开发工具docker build -t myapp .docker run -it myapp bashdocker-compose up五、迁移指南
5.1 从 Docker 切换到 containerd
# 1. 关闭 Dockersystemctl stop docker
# 2. 安装 containerdyum install containerd -y
# 3. 配置 containerdcontainerd config default > /etc/containerd/config.toml
# 4. 修改 kubelet 配置vim /var/lib/kubelet/kubeadm-flags.env# KUBELET_CGROUP_ARGS=--cgroup-driver=cgroupfs# 改为# KUBELET_CGROUP_ARGS=--cgroup-driver=systemd
# 5. 重启服务systemctl restart containerdsystemctl restart kubelet5.2 仍然可以使用 Docker 镜像
# containerd 使用相同的镜像格式# 只需要改变运行时，不需要重建镜像crictl pull nginx:alpine六、总结
6.1 Kubernetes 放弃 Docker 的原因
| 原因 | 说明 |
|---|---|
| 非标准接口 | Docker 有自己的 API，不完全兼容 OCI |
| 不必要的复杂性 | Kubernetes 只需要 containerd |
| 维护负担 | Dockershim 增加开发成本 |
| 标准化趋势 | OCI 成为行业标准 |
6.2 重要澄清
| 误解 | 真相 |
|---|---|
| Docker 被弃用 | Docker 仍是开发工具，只是运行时变化 |
| 需要重建镜像 | 镜像格式不变，可以继续使用 |
| Docker Compose 不可用 | 仍然可用，不影响 |
核心观点：这不是 Docker 的失败，而是技术演进的必然。Docker 推动了容器技术的普及，containerd 将成为 Kubernetes 的标准运行时。
参考资料
- Kubernetes Dockershim Deprecation — 官方博客
- OCI Specifications — OCI 标准
支持与分享
如果这篇文章对你有帮助，欢迎支持作者或分享给更多人
为什么 Kubernetes 要替换 Docker
https://blog.souloss.com/posts/why-the-design/why-kubernetes-replaced-docker/ 部分信息可能已经过时
相关文章 智能推荐
1
为什么 Docker 使用分层镜像
技术科普 深入解析 Docker 镜像分层设计的原理，理解 UnionFS、OverlayFS 如何实现高效的镜像存储与分发。
2
为什么集群需要 Overlay 网络
技术科普 深入解析容器集群中 Overlay 网络的作用，为什么需要 Overlay，以及 VXLAN 等技术原理。
3
认识 Kubernetes：前世今生
云原生 从云计算商业模式的演进出发，梳理容器化技术（LXC → Docker）和 Kubernetes 的诞生背景、核心设计理念及架构概述，理解 K8s 解决了什么核心问题。
4
什么是容器？
技术科普 容器技术深度解析——从容器概念、镜像结构、容器网络、存储、安全，全面掌握容器技术的本质与实践。
5
什么是云计算？
技术科普 一位三年云计算从业者的行业解读——从虚拟化底层机制、容器隔离原理，到 IaaS/PaaS/SaaS 服务模型，再到公有云/私有云/混合云部署形态，全面解析云计算的本质与应用。