Container， 中文名称是容器， Container的爆炸式增长是由 Docker 引发的。 但不久之后，工具、标准和缩写词似乎出现爆炸式增长，到现在为止，尽管有其他容器技术， 如Podman，Buildah等， 但是 Docker 已经成为事实上的容器技术的代表。

那么“Docker”到底是什么？“CRI”和“OCI”等术语是什么意思？ 如果你想进一步了解这些， 请仔细阅读吧。

自从 Docker 掀起了容器热潮以来，新的容器工具、标准和 API 出现了宇宙大爆炸式的爆发。

各种各样的容器技术

在这里，我们将介绍在容器领域听到过的Docker、containerd、OCI、CRI-O 和 runc，解读术语，并且解释容器生态系统如何运作。

为什么我们会澄清这些术语

现在的技术新名词如同雨后春笋， 时髦的名词就比巴黎的时尚服装还要多！

看看Docker Inc（公司）、Docker 容器、Docker 镜像，以及 Docker 开发人员工具之间，作为一个普通人，或者一个普通的开发人员，你能一口气说出这些名词之间的差异吗？

面对这些， 就连Kubernetes 项目联合创始人 Joe Beda ， 都注意到了这一点：

文章一开始就说过，你不是唯一一个感到困惑的人[呲牙]

这可能是一个有助于帮助我们了解什么是 Docker、什么不是Docker的好机会， 尤其是Docker 和containerd 、CRI-O 混杂在一起的时候，可能会有更多人感到困惑和不解， 了解这些技术之间的差别，对于我们学习 Kubernetes，也是特别有用。

我们需要牢记这么一句话：

容器与 Docker 这个名字并不紧密相关。 Docker 并不是唯一的容器技术，我们可以使用其他工具来运行容器。

我们可以使用 Docker 或一堆非 Docker 的其他工具来运行容器。 Docker 只是众多选项之一，Docker公司在生态系统中创建了一些很棒的工具，但不是全部。

因此，如果您认为容器就是 Docker，那么你已经中了Docker的毒，尤其需要继续阅读！

我们将研究容器周围的生态系统以及每个部分的作用。 如果当前正在阅读的你，正在考虑转向 DevOps，关于容器技术的澄清这一点，尤其有用。

鹰的眼睛：容器技术鸟瞰图

容器生态系统由许多令人兴奋的新技术、大量术语和相互竞争的巨头公司（谷歌、微软等）组成。

幸运的是，这些巨头公司偶尔也会联合到一起，就一些标准达成一致。 这些标准有助于提高生态系统的互操作性。 这意味着普通公司可以在不同的平台和操作系统上运行软件，减少对单个公司或项目的依赖。

容器有两大标准：

开放容器计划 (Open Container Initiative,OCI)：一组容器标准，描述镜像格式、运行时和分发。Kubernetes 中的容器运行时接口 (CRI)：允许您在 Kubernetes 中使用不同容器运行时的 API。

下图概述了 Docker、Kubernetes、CRI、OCI、containerd 和 runc 如何在这个生态系统中组合在一起：

此图网址为：https://www.zwchen.com/drawio/container_docker.drawio.html

如果需要源文件， 请私信给我。

让我们依次看看这些项目。

Docker

在容器术语概述中，必须从 Docker 开始。 Docker是最流行的容器开发工具。 而且，对于很多人来说，“Docker”这个名字就是“容器”的代名词。

Docker 通过创建一个非常易于使用的工具来创建和使用容器，从而启动了容器空间。 该工具称为 docker。 它现在被命名为 Docker Engine，并有两个版本：

适用于开发人员工作站的 Docker Desktop，适用于 Windows、Mac 和 Linux适用于服务器的 Docker Engine，可用于 Linux。Docker 堆栈如何工作

Docker Engine 附带了一系列工具，使开发人员或系统管理员可以轻松构建和运行容器。 它基本上是一个用于容器操作的命令行界面（CLI）。

但 docker 命令只是Docker的一小部分。 它实际上调用了一些较低级别的工具来完成繁重的工作：

docker 命令行工具可以构建容器镜像、从注册表中提取镜像、创建、启动和管理容器。 它通过调用一堆较低级别的工具来实现这一点。

Docker 堆栈中的底层工具有哪些？

从下往上看，这些是 docker 用于运行容器的工具：

最低级别 低级别容器运行时 runc 是一个低级容器运行时。 它使用 Linux 的本机功能来创建和运行容器。 它遵循 OCI 标准，并包含 libcontainer，一个用于创建容器的 Go 库。高级容器运行时 containerd 位于低级运行时之上，并添加了一系列功能，例如传输图像、存储和网络。 它还完全支持 OCI 规范。Docker 守护进程 dockerd 是一个守护进程（一个在后台运行的长时间运行的进程），它提供标准 API，并与容器运行时对话 ‍最高级别 Docker CLI 工具 最后，docker-cli 使您能够使用 docker ... 命令与 Docker 守护进程交互。 这使您无需了解较低级别即可控制容器。

因此，实际上，当使用 docker 运行容器时，实际上是通过 Docker 守护进程来运行它，该守护进程调用 containerd，然后使用 runc。

Kubernetes 使用 Docker 吗？

这里有一个非常常见的面试问题：“容器如何在 Kubernetes 中运行？ Kubernetes 使用 Docker 吗？” 标准答案是： 以前是，现在不是了。

最开始，Kubernetes 使用 Docker（Docker Engine）来运行容器。

但是，随着Kubernetes的不断推进和成熟，Kubernetes 演变成一个与具体容器无关的平台。 容器运行时接口 (CRI) API 是在 Kubernetes 中创建的，它允许将不同的容器运行时插入其中。

Docker Engine 是一个比 Kubernetes 更早的项目，没有实现 CRI。 因此，为了帮助实现这一转变，Kubernetes 项目包含了一个名为 dockershim 的组件，它允许 Kubernetes 使用 Docker 运行时来运行容器。

它弥合了旧世界和新世界之间的鸿沟。

什么是shim（垫片）？

shim：垫片

在现实世界中（！），垫片是：

用于对齐零件、使零件贴合或减少磨损的垫圈或薄材料条。

因此，用技术术语来说，垫片是软件系统中的一个组件，它充当不同 API 之间的桥梁，或者充当兼容性层。 当您想要使用第三方组件时，有时会添加垫片，但您需要一些粘合代码才能使其工作。

dockershim之死

但是，从 Kubernetes 1.24 开始，dockershim 组件被完全删除，并且 Kubernetes 不再支持 Docker 作为容器运行时。 相反，您需要选择实现 CRI 的容器运行时。

Kubernetes 集群中 Docker 引擎的逻辑继承者是……containerd （如果你答对了✅，➕ 10 分！）或者你可以使用替代运行时，例如 CRI-O。

这并不是说， Kubernetes 不能运行 Docker 格式的容器。实际上， Containerd 和 CRI-O 都可以在 Kubernetes 中运行 Docker 格式和 OCI 格式的镜像； 而且无需使用 docker 命令或 Docker 守护进程即可完成此操作。

Docker 桌面是什么？

Docker Desktop 是适用于 Mac 和 Windows 的 GUI 应用程序，可让您轻松在笔记本电脑上运行 Docker。 它包括运行 Docker 守护进程的 Linux 虚拟机，还包括 Kubernetes。

Docker Desktop 主要针对开发人员。 它提供了一个非常漂亮的 UI 来可视化您的容器，并且还提供了一种启动 Kubernetes 集群的简单方法。

尽管开发者并不完全需要 Docker Desktop 来使用容器，但这是一个很好的入门方式。 如果您已经在运行 Linux，则可以安装 Docker Engine，然后就可以开始了。

标准和 API：OCI 和 CRI

之前说到， 标准有助于更轻松地在不同平台上运行容器。 现在来看容器标准：

开放容器倡议 (OCI) 规范

OCI(Open Container Initiative, OCI, 开放容器倡议) 是最早为容器世界制定一些标准的组织之一。 它由 Docker 等公司于 2015 年成立。

OCI 由多家科技公司支持，维护容器镜像格式以及容器运行方式的规范。而且，看， 华为也是成员哦～！！！

OCI 规范背后的想法是标准化容器是什么，以及它应该能够做什么。 这意味着您可以自由选择符合规范的不同运行时。 每个运行时都可能有不同的较低级别的实现。

例如：您可以为 Linux 主机使用一种符合 OCI 的运行时，但为 Windows 主机使用不同的运行时。

Kubernetes 容器运行时接口

我们需要讨论的另一个标准是容器运行时接口（CRI）。 这是由 Kubernetes 项目创建的 API。

CRI 是 Kubernetes 用于控制创建和管理容器的不同运行时的接口。

Kubernetes 尽量不关心您使用哪个容器运行时。 它只需要能够向它发送指令——为 Pod 创建容器、终止它们等等。 这就是 CRI 的用武之地。CRI 是现在或将来可能存在的任何类型的容器运行时的抽象。 因此 CRI 使 Kubernetes 更容易使用不同的容器运行时。

Kubernetes 项目不需要单独添加对每个运行时的支持，CRI API 描述了 Kubernetes 如何与任何运行时交互。 只要给定的容器运行时实现了 CRI API，运行时就可以按照自己喜欢的方式创建和启动容器。

以下是 CRI 如何融入容器生态系统的快速可视化：

因此，如果更喜欢使用 Containerd 在 Kubernetes 中运行容器，您可以！ 或者，如果您更喜欢使用 CRI-O，那么也可以。 这是因为这两个运行时都实现了 CRI 规范。

如果您是最终用户（例如开发人员），那么实施通常并不重要。 不同的 CRI 实现之间存在细微的差异，但它们旨在可插拔和无缝更改。

但是，如果您付费从供应商那里获得支持（安全性、错误修复等），那么您可能会选择容器运行时。 例如，红帽的 OpenShift 使用 CRI-O，并提供对其的支持。 Docker 提供了对自己的containerd 的支持。

如何在 Kubernetes 中找到您的容器运行时？

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

您可以通过查看每个节点上的 kubelet 参数来检查正在使用哪个容器运行时。 有一个选项 --container-runtime 和 --container-runtime-endpoint 用于配置要使用的运行时。

容器和 CRI-O

我们已经看到 Docker 引擎调用了一堆较低级别的工具。 但这些工具是什么？ 它们如何组合在一起？

第一层是高级运行时：由Docker创建的containerd和由Red Hat创建的CRI-O。

containerd

containerd 是来自 Docker 的高级容器运行时。 它实现了 CRI 规范。 它从注册表中提取映像，管理它们，然后移交给较低级别的运行时，该运行时使用 Linux 内核的功能来创建我们称为“容器”的进程。

Containerd 诞生于原始 Docker 项目的一部分。 但为什么要这样分开呢？ 嗯，它基本上使 Docker 更加模块化。 这使得 Docker 独特的容器“风味”可以在更多地方运行（例如在 Kubernetes 上），而无需 Docker 守护进程和 Docker CLI 工具。

所以在内部，Docker Engine使用containerd。 当你安装Docker时，它也会安装containerd。

containerd 可以用作 Kubernetes 的容器运行时，因为它通过其 cri 插件实现了 Kubernetes 容器运行时接口 (CRI)。

CRI-O

CRI-O 是另一个高级容器运行时，它实现了 Kubernetes 容器运行时接口 (CRI)。 它是 Containerd 的替代品。 它从注册表中提取容器映像，在磁盘上管理它们，并启动较低级别的运行时来运行容器进程。

是的，CRI-O 是另一个容器运行时。 它脱胎于Red Hat、IBM、Intel、SUSE等公司。

CRI-O 是为了成为 Kubernetes 的容器运行时而创建的。 它提供了启动、停止和重新启动容器的能力，就像containerd一样,CRI-O实现了CRI API，因此它可以用作Kubernetes上的容器运行时。

runc 和其他低级运行时

runc 是一个兼容 OCI 的容器运行时。 它实现 OCI 规范并运行容器进程。runc 有时被称为 OCI 的“参考实现”。

为什么说runc是参考实现？

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

其他容器低级运行时

但是，runc 并不是唯一的低级运行时。 OCI 规范允许其他工具以不同的方式实现相同的功能：

crun 用 C 编写的容器运行时（相比之下，runc 是用 Go 编写的。）firecracker-containerd： 来自 AWS ，它将 OCI 规范实现为单独的轻量级虚拟机（并且它也是支持 AWS Lambda 的相同技术）gVisor： 来自 Google，它创建具有自己内核的容器。 它在名为 runsc 的运行时实现 OCI。Windows 上的 runc 相当于什么？

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

在 Windows 上，情况略有不同。 runc 的对等组件是 Microsoft 的主机计算服务 (HCS)。 它包括一个名为 runhcs 的工具，该工具本身是 runc 的一个分支，并且还实现了开放容器计划规范。

总结

好了，已经写了很长了， 能看到这里的人，都是热爱学习的人！

下面来总结一下。

Docker只是容器生态系统中的一部分。

从理论上讲，有一组开放标准可以更轻松地更换不同的实现。 containerd、runc 和 CRI-O 等项目实现了这些标准的部分内容。

在 Kubernetes 中，您可以选择要使用的容器运行时，只要它支持 CRI API。 您可以使用containerd或CRI-O。

希望在阅读完本文的人，再看到这个云计算全景图中的容器运行时部分时， 能够更多一份理解。

各种各样的容器技术

#CRI#