K8S 中的 CRI、OCI、CRI shim、containerd

我们以 K8S 创建容器的过程为例，来引申出各个概念。

K8S 如何创建容器？

下面这张图，就是经典的 K8S 创建容器的步骤，可以说是冗长复杂，至于为什么设计成这样的架构，继续往下读。

前半部分

CRI（Container Runtime Interface，容器运行时接口）

在 K8S 中，真正负责创建容器运行时的是 kubelet 这个组件。

当 kubelet 对容器运行时进行操作时，并不会直接调用 Docker 的 API，而是通过一组叫作 CRI 的 gRPC 接口来间接执行的。

其实对于 1.6 版本之前的 K8S 来讲，kubelet 是直接与 Docker 的 API 交互的，为什么要单独多出这一层抽象，其实是商战的结果。

当时，Docker 风靡全球，许多公司都希望能在这一领域分一杯羹，纷纷推出了自家的容器运行时。其中最著名的要属 CoreOS 公司的 rkt 项目。虽然 Docker 是 K8S 最依赖的容器运行时，但凭借与 Google 的特殊关系，CoreOS 公司在 2016 年成功地将对 rkt 容器的支持写进了 kubelet 的主代码里。

这下把专门维护 kubelet 的小组 sig-node 坑惨了。因为在这种情况下，ku