CRI 是 Kubernetes 用来控制不同容器运行时的 API，这些容器运行时用来创建和管理容器。CRI 使 Kubernetes 可以更轻松地使用不同的容器运行。

CRI 描述了 Kubernetes 将如何与容器运行时交互，这样 Kubernetes 项目就不用手动添加对每个运行时的支持。

如何实际管理容器由容器运行时决定。

如果你是终端用户，使用哪个具体的实现大多数时候并不重要。

这些 CRI 实现都是可插拔的，并且可以无缝替换。

如果你想要付费从供应商那里获得支持（如安全性、Bug 修复等），那么选择什么运行时可能就变得很重要了。

例如 Red Hat 的 OpenShift 使用 CRI-O 并为其提供支持，而 Docker 则为自己的 containerd 提供支持。

在 Kubernetes 中如何查看运行时？

在 Kubernetes 架构 中，kubelet（每个节点上运行的代理）负责向容器运行时发送指令来开始和运行容器

你可以通过查看每个节点上的 kubelet 参数来检查正在使用哪个容器运行时

选项 --container-runtime 与 --container-runtime-endpoint 用来配置使用的运行时

containerd

containerd 是一个来自 Docker 的高层容器运行时，实现了 CRI 规范，它会从注册中心拉取镜像、管理镜像，并将实际创建运行容器进程的任务交给低层运行时，containerd 项目与 Docker 项目是分开的，这可以让 Docker 更加模块化。因此 Docker 自己也会在内部使用 containerd。当你安装 Docker 时，也会安装 containerd。containerd 通过 cri 插件来实现 Kubernetes Container Runtime Interface (CRI)

CRI-O

CRI-O 是另一个高层容器运行时，实现了 Container Runtime Interface (CRI)

它是一个 containerd 的替代品，可以从注册中心拉取镜像、管理镜像，并将实际运行容器进程的任务交给低层运行时

CRI-O 由 Red Hat、IBM、Intel、SUSE 等开发，从最开始就是专门为了作为 Kubernetes 的容器运行时开发的

和 containerd 一样，它也提供了开始、停止、重启容器的能力

Open Container Initiative (OCI)

OCI 是一组技术规范概念，它们维护着容器镜像格式和容器应该如何运行的规范。OCI 的思想就是，允许在符合规范的不同运行时之间进行选择，这些运行时都有不同的低层实现。

例如，可能有一个适用于 Linux 的 OCI 运行时，以及一个适用于 Windows 的 OCI 运行时，这就是同一个标准可以被许多不同的项目实现的好处，从蓝牙设备到 Java API，这种 “ 一个标准，多种实现 ” 的方式无处不在。

runc

runc 是一个实现了 OCI 规范的容器运行时，它可以运行容器进程。runc 被称为 OCI 的 参考实现。

参考实现是一个已经实现了规范或标准的所有要求的软件，它通常是根据规范开发的第一个软件

runc 提供了 OCI 兼容运行时所期望的所有特性，尽管任何人都可以根据需要实现自己的 OCI 运行时。runc 为容器提供了所有的低层功能，与现有的低层 Linux 特性交互，如命名空间、控制组，它使用这些特性来创建和运行容器进程。runc 的几个替代方案：

crun

一个用 C 语言写的容器运行时（runc 是用 Go 语言写的）

kata-runtime

来自 Katacontainers 项目，它将 OCI 规范实现为独立的轻量级 VM（硬件虚拟化）

gVisor

来自 Google，可以创建拥有自己内核的容器，它在自己的被称为 runsc 的运行时中实现了 OCI

runc 是一个在 Linux 上运行容器的工具，它可以运行在 Linux、裸机或虚拟机上。在 Windows 上有一点不同，与 runc 等价的是微软的主机计算服务（Host Compute Service (HCS)）。它包含一个被称为 runhcs 的工具，其本身也是一个 runc 的分支，同样实现了 Open Container Initiative 规范。