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的故事_第1张图片

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

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

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

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

你可能感兴趣的:(K8S,docker,kubernetes)