Kubernets与Docker的故事-Toy模板网

这篇具有很好参考价值的文章主要介绍了Kubernets与Docker的故事。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

在 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 去操作容器。

Kubernets与Docker的故事,K8S,docker,kubernetes

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

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

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