容器与runC的比较

Question

这两者如何比较？据我所知，runC是容器的运行时环境。这意味着该组件提供了运行容器所必需的环境。那时容器的作用是什么？如果它完成其余的工作（网络，卷管理等），那么Doc​​ker Engine的作用是什么？那容器式垫片怎么样？基本上，我试图了解每个组件的作用。

Answer 1

我将给出一个高级概述来帮助您入门：

• containerd是一个容器运行时，可以管理一个完整的容器生命周期 - 从图像传输/存储到容器执行，监督和网络。
• container-shim handle无头容器，意思是一旦runc初始化容器，它就会将容器放到容器垫片上，而容器垫片就像一些中间人一样。
• runc是轻量级通用运行时容器，符合OCI规范。根据OCI规范，containerc用于生成和运行容器。它也是libcontainer的重新包装。
• grpc用于containerd和docker-engine之间的通信。
• OCI维护运行时和图像的OCI规范。当前的docker版本支持OCI映像和运行时规范。

更多链接：

• Open Container Specification
• A nice dockercon 2016 presentation

Answer 2

Docker引擎是一个整体，它是一个使用户能够运行容器的整体。然后将其分解为单个组件。它被分解为： - docker engine - containerd - runc

runC是实现OCI接口的最低级别组件。它与内核交互并“运行”容器

containerd可以完成设置网络，图像传输/存储等工作 - 它负责完整的容器运行时（这意味着它管理并使runC变得简单，这是实际的容器运行时）。与Docker守护程序不同，它具有减少的功能集;例如，不支持图像下载。

Docker引擎只是做一些高级的事情，比如接受用户命令，从docker注册表中下载图像等。它将很多内容卸载到containerd。

“Docker守护程序将图像准备为Open Container Image（OCI）包，并对containerd进行API调用以启动OCI包.containerd然后使用runC启动容器。”

注意，运行时必须符合OCI，（比如runC），也就是说，它们必须向像collectord这样的管理器公开一个固定的API，以便它们（containerd）可以让它们变得简单（runC）（并要求它们停止/启动容器）

rkt是另一个容器运行时，它不支持OCI，但支持appc规范。但它是一个完整的解决方案，它管理并使自己的生活变得轻松，所以它不需要像爸爸那样的容器。

那就是那个。现在让我们添加另一个组件（和另一个接口） - Kubernetes

Kubernetes可以运行任何满足CRI - 容器运行时接口的东西。

您可以使用k8s运行rkt，因为rkt满足CRI - 容器运行时接口。 Kubernetes没有要求任何其他东西，它只需要CRI，它没有给出关于如何运行容器的FF，OCI与否。

containerd不支持CRI，但是cri-containerd是容器周围的垫片。因此，如果您想使用Kubernetes运行containerd，则必须使用cri-containerd（这也是Kubernetes的默认运行时）。 cri-containerd最近改名为CRI插件。

如果你想在混音中加入docker引擎，你也可以做到。使用dockershim，它会将CRI垫片添加到docker引擎。

现在，就像containerd可以为runC（容器运行时）管理和简化生活一样，它也可以为其他容器运行时管理并简化生活 - 事实上，对于支持OCI的每个容器运行时 - 就像Kata容器运行时一样（称为~kata-runtime~ - https://github.com/kata-containers/runtime。） - 运行kata容器，Clear Container运行时（由Intel提供）。

现在我们知道rkt满足CRI，cri-containerd（又名CRI Plugin）也是如此。

注意容器在这里做什么。它不是运行时，它是runC的管理器，它是容器运行时。它只管理图像下载，存储等。哎呀，它甚至不满足CRI。

这就是我们拥有CRI-O的原因。它就像containerd一样，但它实现了CRI。 CRI-O需要容器运行时来运行映像。它将为该运行时管理并简化生活，但它需要运行时。它将采用符合OCI的任何运行时。因此，自然地，~kata-runtime~符合CRI-O，runC符合CRI-O。

与Kubernetes一起使用很简单，将Kubernetes指向CRI-O作为容器运行时。 （是的，CRI-O，但CRI-O和实际的容器运行时IS。而Kubernetes指的是那对幸福的情侣，当它表示容器运行时）。

就像containerd拥有Docker使其真正可用，并且为了容器管理和使生活更轻松，CRI-O需要有人来处理图像管理 - 它有buildah，umochi等。

crun是另一个符合OCI并用C语言编写的运行时。它由RedHat提供。

我们已经讨论过，kata-runtime是另一个符合OCI的运行时。因此，我们可以像我们讨论的那样使用kata-runtime和CRI-O。

注意，这里，kubelet通过CRI与CRI-O通信。 CRI-O正在谈论cc-runtime（这是英特尔明确容器的另一个运行时，是的，符合OCI），但它也可能是kata-runtime。

不要忘记containerd，它可以为所有OCI投诉运行时管理并简化生活 - runC确定，还有kata-runtime，cc-runtime

在这里，请注意运行时从runC移动到kata-runtime。为此，在containerd配置中，只需将运行时更改为“kata”

毋庸置疑，它可以通过CRI-O或者cri-containerd（又名CRI插件）在Kubernetes上运行。

这真的很酷：顶部：

Kubernetes，由其大使Kubelet先生代表这里运行任何满足CRI的东西。现在，我们有几个候选人可以。 - Cri-containerd使容器做到了。 - CRI-O原生地做。 - Dockershim让docker引擎做到了。

现在，上面的所有3个人都可以管理并使所有符合OCI标准的运行时生活变得简单 - runC，kata-runtime，cc-runtimes。

我们还有frakti，它满足CRI，就像rkt一样，但不满足OCI，并且捆绑了它自己的容器运行时。

在这里，我们有CRI-O在行动中管理和使OCI兼容的kata-runtime和runC两者都很容易

我们还有一些运行时：

• 铁路车 - 符合OCI标准，用铁锈书写
• Pouch - 阿里巴巴改进的runC
• nvidia运行时 - nvidia的runC分支

ref：https://github.com/darshanime/notes/blob/master/kubernetes.org#notes

Answer 3

runc是containerd的组件之一，用于处理运行容器的内核级交互。在早期版本中，containerd本质上是围绕runc的高级抽象，但现在它的方式不止于此。来自container.io：

runc是containerd的一个组件，是容器的执行者。 containerd具有比仅执行容器更广泛的范围：下载容器映像，管理存储和网络接口，使用正确的参数调用runc来运行容器。

来自同一来源的This image很好地描述了这一点。

Docker Engine是最终用户产品，它使用containerd作为主要组件，并实现不属于containerd范围的其他功能。

请注意，Docker将containerd作为一个单独的组件提取出来，因此它也可以被其他产品使用和开发。

[编辑]我写了更多关于这个术语qazxsw poi的文章