参考： Docker，containerd，CRI，CRI-O，OCI，runc 分不清？看这一篇就够了
Docker, containerd, CRI-O and runc之间的区别？
Docker、Podman、Containerd 谁才是真正王者？
CRI-O vs Podman vs Docker vs CRI-containerd

1 容器的主要标准：

• Open Container Initiative (OCI) ，定义容器和镜像的标准

• Container Runtime Interface (CRI)，它定义了Kubernetes和下面的容器运行时之间的API。

---

• OCI：

• OCI (Open Container Initiative)，是一个轻量级，开放的治理结构（项目）。在 Linux 基金会的支持下成立，致力于围绕容器格式和运行时创建开放的行业标准。

• OCI 项目由 Docker、CoreOS 和容器行业中的其它领导者在 2015 年 6 月的时候启动，OCI 的技术委员会成员包括 Red Hat、Microsoft、Docker、Cruise、IBM、Google、Red Hat 和 SUSE 等。

• CRI：

• CRI（Container Runtime Interface）是 Kubernetes v1.5 引入的容器运行时接口，它将 Kubelet 与容器运行时解耦，将原来完全面向 Pod 级别的内部接口拆分成面向 Sandbox 和 Container 的 gRPC 接口，并将镜像管理和容器管理分离到不同的服务。

2 CRI-O, Docker, Containerd三者区别

1. CRI-O：

1. 实现了容器运行时接口（CRI）的高级别容器运行时，实现了CRI规范。

2. 可以使用 OCI（开放容器倡议）兼容的运行时，是 containerd 的一个替代品。

3. 是专门为Kubernetes创建的一个容器运行时，与 containerd 相同，提供了拉取、推送镜像，管理网络，存储的能力，

4. 通过直接调用底层的runc，实现启动、停止和重启容器的管理.

5. CRI-O 诞生于 RedHat、IBM、英特尔、SUSE、Hyper 等公司。

2. Podman:

1. Podman原来是CRI-O项目的一部分，后来被分离成了一个单独的项目libpod。

3. Docker：

1. 需要先调用dockershim，然后调用docker，再调用containerd，最后调用底层的 runc.

4. CRI-Containerd：

1. 是CRI的实现，通过Containerd调用底层的runc.

5. Containerd：

1. Containerd是一个进程，是CRI-Containerd的实现，用来拉取、推送镜像，管理网络，存储，调用底层runc来运行容器，并且管理容器的运行。

2. containerd 是一个来自 Docker 的高级容器运行时，并实现了 CRI 规范。

3. containerd从 Docker 项目中分离出来，使Docker更加模块化，之后 containerd 被捐赠给云原生计算基金会（CNCF）为容器社区提供创建新容器解决方案的基础。

4. Docker 内部使用 containerd，安装 Docker 时也会安装 containerd。

5. containerd 通过其 CRI 插件实现了 Kubernetes 容器运行时接口（CRI），它可以管理容器的整个生命周期，包括从镜像的传输、存储到容器的执行、监控再到网络。

---

• runc:

• 底层容器运行时，或者实际创建和运行容器的组件，它包括libcontainer，这是一个基于go的本地实现，用于创建、启动、停止和重启容器的管理。

• runc 是轻量级的通用运行时容器，它遵守 OCI 规范，是实现 OCI 接口的最低级别的组件，与内核交互创建并运行容器。

• runc 为容器提供了所有的低级功能，与现有的低级 Linux 功能交互，如命名空间和控制组，它使用这些功能来创建和运行容器进程。

• runc 是一个在 Linux 上运行容器的工具，所以这意味着它可以在 Linux 上、裸机上或虚拟机内运行。

• runc 的几个替代品：

• crun [5]：一个用 C 语言编写的容器运行时（相比之下，runc 是用Go编写的。）来自 Katacontainers 项目的 kata-runtime [6] 它将 OCI 规范实现为单独的轻量级虚拟机（硬件虚拟化）。

• Google 的 gVisor [7]，创建了拥有自己内核的容器，在其运行时中实现了 OCI，称为 runsc。

• dockershim：

• Docker比Kubernetes更古老，没有实现CRI。dockershim把Docker连接到Kubernetes上，或者是Kubernetes连接到Docker上。

• dockershim支持将 Docker 被硬编码到 Kubernetes 中。随着容器化成为行业标准，Kubernetes 项目增加了对额外运行时的支持，比如通过 Container Runtime Interface (CRI) 容器运行时接口来支持运行容器。因此 dockershim 成为了 Kubernetes 项目中的一个异类，对 Docker 和 dockershim 的依赖已经渗透到云原生计算基金会（CNCF）生态系统中的各种工具和项目中，导致代码脆弱。

• 2022 年 4 月 dockershim 将会从 Kubernetes 1.24 中完全移除。今后 Kubernetes 将取消对 Docker 的直接支持，而倾向于只使用实现其容器运行时接口的容器运行时，这可能意味着使用 containerd 或 CRI-O。这并不意味着 Kubernetes 不能运行 Docker 格式的容器。

• containerd 和 CRI-O 都可以运行 Docker 格式（实际上是 OCI 格式）的镜像，它们只是无需使用 docker 命令或 Docker 守护程序。

3 Docker，k8s，CRI, OCI, containerd和runc关系图

4 Docker VS Podman

Podman与Linux内核交互，通过runC容器运行时进程而不是Daemon来管理容器。Buildah实用程序用于替代Docker build作为容器镜像构建工具，Docker push被Skopeo替代，用于在注册表和容器引擎之间移动容器镜像。

(1) 架构

Docker使用守护进程，一个正在后台运行的程序，来创建镜像和运行容器。Podman是无守护进程的架构，这意味着它可以在启动容器的用户下运行容器。Docker有一个由守护进程引导的客户端——服务器逻辑架构;但Podman不需要此类守护进程。

(2) Root特权

由于Podman没有守护进程来管理其活动，也无需为其容器分配Root特权。Docker最近在其守护进程配置中添加了Rootless模式，但Podman首先使用了这种方法，并将其作为基本特性进行了推广。原因如下。

(3) 安全

Podman比Docker安全吗?Podman允许容器使用Rootless特权。Rootless容器被认为比Root特权的容器更安全。在Docker中，守护进程拥有Root权限，这使得它们易成为攻击者的首选入侵点。
Podman中的容器默认情况下不具有Root访问权限，这在Root级别和Rootless级别之间添加了一个自然屏障，提高了安全性。不过，Podman可以同时运行Root容器和Rootless容器。

(4) Systemd

如果没有守护进程，Podman需要另一个工具来管理服务并支持后台运行的容器。Systemd为现有容器创建控制单元或用来生成新容器。Systemd还可以与Podman集成，允许它在默认情况下运行启用了Systemd的容器，从而无需进行任何修改。
通过使用Systemd，供应商可以将他们的应用程序封装为容器用来安装、运行和管理，因为现在大多数应用程序都是通过这种方式打包和交付的。

(5) 构建镜像

作为一款自给自足的工具，Docker可以自己构建容器镜像。Podman则需要另一种名为Buildah的工具的辅助，该工具充分体现了它的特殊性：它是为构建镜像而设计的，而不是为构建容器而生。

(6) Docker Swarm

Podman不支持Docker Swarm，这可能会在某些项目中被刨除在外，因为使用Docker Swarm命令会产生一个错误。然而，Podman最近增加了对Docker Compose的支持，使其与Swarm兼容，从而克服了这个限制。当然，Docker由于其原生的特性，与Swarm当然融合得很好。

(7) All in one vs 模块化

Docker是一个独立的、强大的工具，在整个循环中处理所有的容器化任务，有优点也有缺点。Podman采用模块化的方法，依靠专门的工具来完成特定的任务。

5 Docker容器运行架构图

当用 docker命令运行一个容器时，实际上是通过 docker守护进程调用 containerd，然后 containerd调用runc运行容器。

• docker:命令行工具，终端用户使用这个命令来和docker进行交互

• containerd，containerd是一个进程，用来拉取、推送镜像，管理网络，存储，然后使用runc来运行容器，并且管理容器的运行

• runc:这是底层容器运行时，或者实际创建和运行容器的组件)。它包括libcontainer，这是一个基于go的本地实现，用于创建容器

6 原始容器运行时Runc

最终用户到实际的容器调用链示意图：

• runc 是一个命令行客户端，用于运行根据 Open Container Initiative (OCI) 格式打包的应用程序，并且是 Open Container Initiative 规范的兼容实现。

• runc 符合容器和管理容器映像的开放容器计划(OCI) 和规范，也有其他符合 OCI 的运行时，甚至可以运行符合 OCI 标准的虚拟机，Kata Containers 与gVisor就是符合符合 OCI 标准的虚拟机。gVisor 为代表的用户态 Kernel 方案是安全容器的未来，只是现在还不够完善。

• runc 希望提供一个“ OCI 包”，它只是一个根文件系统和一个config.json 文件。而不是Podman 或 Docker 那样有“镜像”概念，所以不能只执行runc run nginx:latest这样来启动一个容器。

• Runc 符合 OCI 规范（具体来说，是runtime-spec），可以使用 OCI 包并从中运行一个容器。值得重申的是，这些bundle并不是“容器镜像”，它们要简单得多。层、标签、容器注册表和存储库等功能 - 所有这些都不是 OCI 包甚至运行时规范的一部分。有一个单独的 OCI-spec （image-spec ）定义镜像。