一、背景

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

二、K8s（版本 < 1.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 运行时有两个实现方案：

1. containerd
   containerd 是 Docker 的一部分，提供的 CRI 都是由 Docker 提供的。
2. CRI-O：
   CRI-O 在本质上属于纯 CRI 运行时，因此不包含除 CRI 之外的任何其他内容。

四、OCI 是啥？

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

1. CRI 运行时
2. OCI 运行时

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

四、CRI、OCI 之间的关系？

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

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

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

五、参考资料

• https://mp.weixin.qq.com/s/GHjvvTJ8ZerIyCqXB1BSUQ
• https://blog.csdn.net/weixin_40864891/article/details/86655846