K8s 为什么要弃用 Docker？

在写“K8s”系列文章的过程中，很多读者留言询问 K8s 弃用 Docker 的事，担心现在学习 Docker 是否还值得，是不是该切换到 containerd 或其他运行时。

这些怀疑有一定的道理。两年前，K8s 发布“弃用 Docker”的消息时，确实在社区引起了“轩然大波”，影响甚至蔓延到了社区之外，K8s 不得不写了好几篇博客来重复解释原因。

两年过去了，虽然 K8s 1.24 已经实现了“弃用 Docker”的目标，但很多人似乎对这一点还不是很清楚。所以本篇文章就来聊聊这个话题。

CRI（容器运行时接口）

要理解 K8s 为何“弃用 Docker”，我们得回顾一下 K8s 的发展史。

2014 年，Docker 正处于鼎盛时期，而 K8s 刚刚诞生。虽然它得到了 Google 和 Borg 的支持，但它还是比较新的。

因此，K8s 首先选择支持 Docker 。

快进到 2016 年，CNCF 成立一年，K8s 也发布了 1.0 版本，可以正式用于生产环境。这些都表明 K8s 已经长大了。

于是宣布加入 CNCF，成为第一个 CNCF 托管项目。它想利用基金会的力量联合其他厂商来“打倒”Docker。

在 2016 年底的 1.5 版本中，K8s 引入了新的接口标准：CRI：Container Runtime Interface 容器运行时接口。

CRI 使用ProtoBufferandgPRC来指定kubelet应该如何调用容器运行时来管理容器和镜像，但这是一组与以前的 Docker 调用完全不兼容的新接口。

显然它不想再和 Docker 绑定，在底层允许访问其他容器技术（如 rkt、kata 等），可以随时“踢开” Docker。

但此时 Docker 已经非常成熟，市场的惯性也非常强。各大云厂商不可能一下子全部替换掉 Docker。

因此，K8s 只能同时提供一种“折中”的方案，在