docker、containerd、CRI、OCI、runC分别是什么

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

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

因为在这种情况下，kubelet 的任何重要功能更新都必须同时考虑 Docker 和 rkt 这两种容器运行时的处理场景，并分别更新 Docker 和 rkt 的代码。这不仅降低了开发效率，还给项目的稳定性带来了极大的隐患。CNCF官方一看这可不行，今天出个 rkt，明天出个 xxx，这下我们组也不用干活了，每天使劲折腾兼容性得了。所以把 kubelet 对容器运行时的操作统一抽象成了一个 gRPC 接口，然后告诉大家，你们想做容器运行时可以啊，我热烈欢迎，但是前提是必须用我这个接口。这一层统一的容器操作接口，就是 CRI ，这样 kubelet 就只需要跟这个接口打交道就可以了。而作为具体的容器项目，比如 Docker、 rkt，它们就只需要自己提供一个该接口的实现，然后对 kubelet 暴露出 gRPC 服务即可。

容器运行时意思就是能够管理容器运行的整个生命周期，具体一点就是如何制作容器的镜像、容器镜像格式是什么样子的、管理容器的镜像、容器镜像的分发、如何运行一个容器以及管理创建的容器实例等等。运行时分成low-level运行时和high-level运行时，low-level运行时专注于如何创建一个容器例如runc和kata，high-level包含了更多上层功能，比如镜像管理，以docker和containerd为代表。

K8s的kubelet是调用容器运行时创建容器的，但是容器运行时这么多不可能逐个兼容，K8s在对接容器运行时定义了CRI接口，容器运行时只需实现该接口就能被使用。下图分别是k8s使用docker和containerd的调用链：

使用containerd时CRI接口是在containerd代码中实现的；使用docker时的CRI接口是在k8s的代码中实现的，叫做docker-shim(kubernetes/pkg/kubelet/dockershim/docker_service.go)，这部分代码在k8s代码中是历史原因，当时docker是容器方面行业事实上的标准，但随着越来越多运行时实现了CRI支持，docker-shim的维护日益变成社区负担，在最新的K8s版本中，该部分代码目前已经移出。

CRI 只是 K8S 推出的一个标准而已，当时的 K8S 还没有达到如今这般武林盟主的统治地位，各家公司的容器项目也不能说我只跟 K8S 绑死，只适配 CRI 接口。所以， shim （垫片）就诞生了。

一个 shim 的工作就是就是作为适配器将各种容器运行时本身的接口适配到 K8S 的 CRI 接口上，以便用来响应 kubelet 发起的 CRI 请求。

每一个容器运行时都可以自己实现一个 CRI shim，用来把 CRI 请求 “翻译”成自家容器运行时能够听懂的请求。

如果你用 Docekr 作为容器运行时，那你的 CRI shim 就是 dockershim，因为当时 Docker 的江湖地位很高，kubelet 是直接集成了 dockershim 的，所以 K8S 创建容器的前半部分如下图红框所示：

如果 containerd 挂掉的话，整个宿主机上所有的容器都得退出了，而引入 containerd-shim 就可以避免这种问题。

runc是 OCI的一个标准实现（Docker 被逼无耐将 libcontainer 捐献出来然后改名为 runc ）

OCI（open Container Initiative）容器标准化组织的主要目的是推进容器技术的标准化。对容器标准进行准确的定义。其主要目的是为了解决容器标准混乱的问题。没有统一的容器标准，工业界就无法按照统一的标准进行容器开发。因此OCI于2015年由docker牵头和其他公司制定了相应的容器标准。

containerd-shim  通过调用 runc 来创建容器，runc 启动完容器后本身会直接退出，containerd-shim 则会成为容器进程的父进程, 负责收集容器进程的状态, 上报给 containerd, 并在容器中 pid 为 1 的进程退出后接管容器中的子进程进行清理, 确保不会出现僵尸进程。

从 K8S (v1.24) 版本开始，K8S 弃用 Docker，使用 containerd 作为容器运行时。

至于为什么要用 containerd 作为容器运行时，也有商业竞争的原因。当时 docker 公司为了跟 K8S 竞争，搞了个 Docker Swarm，并且把架构进行了切分：把容器操作都移动到一个单独的 containerd 进程中去，让 Docker Daemon 专门负责上层的封装编排。

但是 swarm 就是弟弟，根本打不过k8s，于是 Docker 公司只能后退一步，将 containerd项目捐献给 CNCF 基金会，而 K8S 也见好就收，既然 Docker 已先退了一步，那就干脆优先支持原生Docker 衍生的容器运行时：containerd

为了适配 CRI 标准，专门起了一个单独的进程：CRI-containerd，这是因为还没有捐给 K8S 的时候 containerd 会去适配其他的项目（Docker Swarm）

到了 containerd 1.1 版本，K8S 去掉了 CRI-Contained 这个 shim，直接把适配逻辑作为插件的方式集成到了 containerd 主进程中，现在这样的调用就更加简洁了。

除此之外，K8S 社区也做了一个专门用于 K8S 的运行时 CRI-O，它直接兼容 CRI 和 OCI 规范。