大家好，欢迎来到IT知识分享网。

容器流行是由Docker拉开的序幕。但不久之后，容器生态更多是由于工具、标准和名词而爆炸。那么“docker”到底是什么，像“CRI”和“OCI”这样的术语是什么意思？你甚至应该关心吗？请继续阅读以找出答案。

自从 Docker 掀起容器狂潮以来，新的容器工具、标准和 API 出现了寒武纪的爆炸式增长。

但是，除非你正处在技术的煤炭面上，否则很难跟上。大型科技公司之间的权力博弈可能会增加我们其他人的困惑。

在本文中，我们将介绍您在集装箱土地上听到的所有主要名称，尝试为您解读行话，并解释容器生态系统的工作原理。

我们是如何走到这一步的

Docker Inc（公司）、Docker 容器、Docker 镜像和我们都熟悉的 Docker 开发人员工具之间存在差异。要了解的主要内容是：

容器与名称 Docker 并不紧密耦合。可以使用其他工具来运行容器。

你可以用 Docker 或其他一些不是 Docker 的工具运行容器。Docker只是众多选择之一，Docker（公司）在生态系统中创造了一些很棒的工具，但不是全部。

因此，如果您认为容器只是关于 Docker 的，那么请继续阅读！我们将研究围绕容器的生态系统以及每个部分的作用。如果您正在考虑迁移到 DevOps，这将特别有用。

鸟瞰图

容器生态系统由许多令人兴奋的技术、大量的行话和相互竞争的大公司组成。

幸运的是，这些公司偶尔会在脆弱的休战中走到一起，商定一些标准。标准有助于使生态系统更具互操作性。这意味着您可以在不同的平台和操作系统上运行软件，并且减少对单个公司或项目的依赖。

容器有两个大标准：

开放容器计划（OCI）：一组容器标准，描述映像格式、运行时和分发。

Kubernetes 中的容器运行时接口 （CRI）：允许您在 Kubernetes 中使用不同容器运行时的 API。

我们将在下面看看这些。但首先，这张图概述了Docker，Kubernetes，CRI，OCI，containerd和runc如何在这个生态系统中结合在一起：

Docker

在我们的容器术语清单中，我们必须从 Docker 开始。它是用于处理容器的最流行的开发人员工具。而且，对于很多人来说，“Docker”这个名字是“容器”这个词的同义词。

Docker通过创建一个非常符合人体工程学（易于使用）的工具来创建和使用容器，从而启动了容器空间。该工具被称为docker。它现在被标记为Docker引擎，有两个版本：

适用于开发人员工作站的 Docker 桌面，适用于 Windows、Mac 和 Linux

适用于您的服务器的 Docker 引擎，适用于 Linux。

Docker 堆栈的工作原理

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

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

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

Docker 堆栈中的较低级别工具是什么？

从下到上，这些是 docker 用来运行容器的工具：

• 最低级别 低级别容器运行时。runc 是一个低级容器运行时。它使用 Linux 的本机功能来创建和运行容器。它遵循 OCI 标准，它包括 libcontainer，一个用于创建容器的 Go 库。
• 高级容器运行时。containerd 位于低级运行时之上，并添加了一系列功能，例如传输图像、存储和网络。它还完全支持 OCI 规范。
• Docker 守护进程。dockerd 是一个守护进程（一个长时间运行的进程，在后台保持运行），它提供了一个标准的 API，并与容器运行时 1 对话。

• 最高级别 Docker CLI 工具。最后，docker-cli 使您能够使用 docker 与 Docker 守护程序进行交互……命令。这使您无需了解较低级别即可控制容器。

所以，实际上，当你使用 docker 运行一个容器时，你实际上是通过 Docker 守护进程来运行它，它调用 containerd，然后使用 runc。

如果你想了解更多关于容器生态系统的信息，你应该看看Nigel Poulton的书，其中更详细地解释了它：

Kubernetes 使用 Docker 吗？

一个非常常见的问题是“容器如何在 Kubernetes 中运行？”。Kubernetes 使用 Docker 吗？好吧，它不再了 – 但它曾经。

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

但是，随着时间的推移，Kubernetes 演变成一个与容器无关的平台。容器运行时接口 （CRI） API 是在 Kubernetes 中创建的，它允许将不同的容器运行时插入其中。

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

dockershim 组件的消亡

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

Kubernetes 集群中 Docker Engine 的逻辑继承者是……集装箱。（如果你答对了，得10分！或者，您可以使用替代运行时，如 CRI-O。

这并不意味着 Kubernetes 不能运行所谓的 Docker 格式的容器。containerd 和 CRI-O 都可以在 Kubernetes 中运行 Docker 格式和 OCI 格式的镜像;他们可以在不必使用 docker 命令或 Docker 守护程序的情况下做到这一点。

唷。希望能解决这个问题。

Docker Desktop怎么样？

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

Docker Desktop主要针对开发人员。它提供了一个非常好的UI来可视化你的容器，还包括一个启动Kubernetes集群的简单方法。

您不需要 Docker Desktop 来处理容器，但这是一种不错的入门方式。如果你已经在运行Linux，你可以安装Docker引擎，你会很高兴。

标准和 API：OCI 和 CRI

我们之前看到，一些标准有助于更轻松地在不同平台上运行容器。但这些标准是什么？

Open Container Initiative (OCI) 标准

OCI 是为容器世界创建一些标准的首批努力之一。它由Docker和其他人于2015年成立。

OCI 得到了许多科技公司的支持，并维护容器映像格式以及容器应如何运行的规范。

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

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

Kubernetes 容器运行时接口

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

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

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

CRI API 不是 Kubernetes 项目需要单独添加对每个运行时的支持，而是描述了 Kubernetes 将如何与任何运行时交互。只要给定的容器运行时实现了 CRI API，运行时就可以随心所欲地创建和启动容器。

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

你可以为 Kubernetes 选择自己的容器运行时

来源：教程作品

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

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

但是，如果您付费从供应商处获得支持（安全性、错误修复等），则可能会为您选择容器运行时。例如，Red Hat的OpenShift使用CRI-O，并为其提供支持。Docker为他们自己的容器提供支持。

containerd 与 CRI-O

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

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

containerd

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

containerd 诞生于原始 Docker 项目的一部分。但是为什么会这样把它分开呢？好吧，它基本上使Docker更加模块化。这使得Docker的特殊容器“风格”可以在更多的地方运行（比如在Kubernetes上），而不需要Docker守护进程和Docker命令行工具。

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

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

CRI-O

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

是的，CRI-O 是另一个容器运行时。它诞生于Red Hat，IBM，Intel，SUSE等。有关创建 CRI-O 的原因的背景故事，请参阅此处。

CRI-O 被创建为 Kubernetes 的容器运行时。它提供了启动、停止和重新启动容器的功能，就像 containerd 一样。

就像containerd一样，CRI-O实现了CRI API，因此它可以用作Kubernetes上的容器运行时。

runc and other low-level runtimes

runc 是与 OCI 兼容的容器运行时。它实现 OCI 规范并运行容器进程。

runc 有时被称为 OCI 的“参考实现”。

什么是参考实现？What is a reference implementation?

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

其他低级运行时

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

• crun 一个用 C 编写的容器运行时（相比之下，runc 是用 Go 编写的。
• firecracker-containerd 来自 AWS 的容器，它将 OCI 规范作为单独的轻量级虚拟机实施（它也与支持 AWS Lambda 的技术相同）
• 来自Google的gVisor，它创建具有自己内核的容器。它在其运行时实现 OCI，称为 runsc。

总结

好了，我们已经走到了这段旅程的尽头。但是我们学到了什么？

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

有一套开放标准，从理论上讲，可以更容易地交换不同的实现。像containerd，runc和CRI-O这样的项目实现了这些标准的一部分。

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