K8s、Docker、CRI、OCI 之间的爱恨情仇

一、背景

由于最近知道了 K8s 新版本（v1.20）确定弃用 Docker 的消息，为了明确是否会对现有系统架构产生响，所以对涉及到的相关技术进行了一定的梳理（索性的是对现有的系统架构基本无影响：>）。

二、K8s（版本 < 1.20） 与 Docker 的关系

首先，通过一张图片来说明 K8s（版本

那就是 K8s 只能与 CRI 运行时通信

对于啥是 CRI 运行时？我们暂可以简单的将 Ta 理解为与 Docker 同等的存在（另外一个容器容器运行时）。Ok，下面我们来看图说话吧：

通过上边的图片我们可以看到，K8s 是通过 docker-shim 作为桥接服务，将 CRI 转换为 Docker API，然后与 Dokcer 进行通信的。

三、CRI 是啥？

CRI（Container Runtime Interface）是 K8s 定义的一组与容器运行时进行交互的接口，用于将 K8s 平台与特定的容器实现解耦。在 K8s 早期的版本中，对于容器环境的支持是通过 hard code 方式直接调用 Docker API 的，后来为了支持更多的容器运行时和更精简的容器运行时，K8s 提出了CRI。

CRI 运行时有两个实现方案：

containerd

containerd 是 Docker 的一部分，提供的 CRI 都是由 Docker 提供的。

CRI-O：

CRI-O 在本质上属于纯 CRI 运行时，因此不包含除 CRI 之外的任何其他内容。

四、OCI 是啥？

当我们谈论「容器运行时」时，请注意我们到底是在谈论哪种类型的运行时，这里运行时分为两种：

CRI 运行时

OCI 运行时

OCI（Open Container Initiative），可以看做是「容器运行时」的一个标准，Ta 使用 Linux 内核系统调用（例如：cgroups 与命名空间）生成容器，按此标准实现的「容器运行时」有 runC 和 gVisor。

四、CRI、OCI 之间的关系？

还是通过图片来说明下吧：

通过上边的图片，我们可以得出如下结论：

实际对容器的操作最终还是要交给 OCI，CRI 也只是个中转

五、参考资料

------------END-----------