在 2016 年底的 1.5 版里，Kubernetes 引入了一个新的接口标准：CRI ，Container Runtime Interface。

CRI 采用了 ProtoBuffer 和 gPRC，规定 kubelet 该如何调用容器运行时去管理容器和镜像，但这是一套全新的接口，和之前的 Docker 调用完全不兼容。

 Kubernetes 也只能同时提供一个“折中”方案，在 kubelet 和 Docker 中间加入一个“适配器”，把 Docker 的接口转换成符合 CRI 标准的接口。

而 Docker把原本单体架构的 Docker Engine 拆分成了多个模块，其中的 Docker daemon 部分就捐献给了 CNCF，形成了 containerd。

containerd 作为 CNCF 的托管项目，自然是要符合 CRI 标准的。但 Docker 出于自己诸多原因的考虑，它只是在 Docker Engine 里调用了 containerd，外部的接口仍然保持不变，也就是说还不与 CRI 兼容。

 Kubernetes 里就出现了两种调用链：

• 第一种是用 CRI 接口调用 dockershim，然后 dockershim 调用 Docker，Docker 再走 containerd 去操作容器。
• 第二种是用 CRI 接口直接调用 containerd 去操作容器。

由于都是用 containerd 来管理容器，所以这两种调用链的最终效果是完全一样的，但是第二种方式省去了 dockershim 和 Docker Engine 两个环节，更加简洁明了，损耗更少，性能也会提升一些。

所以，“弃用 Docker”对 Kubernetes 和 Docker 来说都不会有什么太大的影响，因为他们两个都早已经把下层都改成了开源的 containerd，原来的 Docker 镜像和容器仍然会正常运行，唯一的变化就是 Kubernetes 绕过了 Docker，直接调用 Docker 内部的 containerd 而已。

Docker 是一个完整的软件产品线，不止是 containerd，它还包括了镜像构建、分发、测试等许多服务，甚至在 Docker Desktop 里还内置了 Kubernetes。

此文章为7月Day10学习笔记，内容来源于极客时间《Kubernetes入门实战课》，推荐该课程。