容器与runC的比较

时间：2017-01-14 00:57:20

标签： docker runc

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

3 个答案:

答案 0 :(得分：56)

我将提供一个高级概述，以帮助您入门：

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

runC, containerD

更多链接：

答案 1 :(得分：15)

整个Docker引擎是一个整体，它使用户能够运行容器。然后将其分解为单独的组件。它分为： -码头工人引擎 -集装箱 -runc

enter image description here

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

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

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

“ Docker守护程序将映像准备为开放容器映像（OCI）捆绑包，并对containerd进行API调用以启动OCI捆绑包。containeded然后使用runC启动容器。”

请注意，运行时必须与OCI兼容（例如runC是），也就是说，它们必须向诸如容器化的管理器公开固定的API，以便它们（包含）可以使它们（runC）的生活更轻松（并且要求他们停止/启动容器）

enter image description here

rkt是另一个容器运行时，它尚不支持OCI，但支持appc规范。但这是一个完善的解决方案，它可以管理并使生活变得轻松，因此不需要像爸爸这样的容器。

就是这样。现在，我们将另一个组件（和另一个接口）添加到混合中-Kubernetes

Kubernetes可以运行满足CRI-容器运行时界面的任何内容。

您可以使用k8s运行rkt，因为rkt满足CRI-容器运行时界面。 Kubernetes不需要任何其他要求，它只需要CRI，就运行容器的方式（不管是否使用OCI）都没有任何帮助。

containerd不支持CRI，但cri-containerd是围绕容器的填充程序。因此，如果您想使用Kubernetes来运行容器，则必须使用cri-containerd（这也是Kubernetes的默认运行时）。 cri-containerd最近被重命名为CRI插件。

如果您也想同时使用Docker引擎，则可以这样做。使用dockershim，它将CRI填充程序添加到docker引擎。

enter image description here

现在，就像容器化一样，它可以管理runC（容器运行时）并使生活变得轻松，它也可以管理其他容器运行时并使生活变得更轻松-实际上，对于每个支持OCI的容器运行时（例如Kata容器运行时） （称为〜kata-runtime〜-https://github.com/kata-containers/runtime。）-运行kata容器，Clear Container运行时（由Intel提供）。

现在，我们知道rkt可以满足CRI，cri-containerd（也称为CRI插件）也可以满足。

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

这就是为什么我们有CRI-O。就像容器一样，但是它实现了CRI。 CRI-O需要一个容器运行时来运行映像。它可以管理该运行时并使生活变得轻松，但是它需要一个运行时。它将花费所有符合OCI的运行时。因此，很自然，〜kata-runtime〜是CRI-O兼容的，runC是CRI-O兼容的。

与Kubernetes一起使用很简单，将Kubernetes指向CRI-O作为容器运行时。 （是的，CRI-O，但是CRI-O和实际的容器运行时是IS。Kubernetes在说容器运行时时指的是那对幸福的夫妻）。

就像Containerd拥有使它真正可用的docker一样，为了管理和简化Container的生活，CRI-O需要有人来管理图像管理-它具有buildah，umochi等。

crun是另一个符合OCI且使用C语言编写的运行时。它是RedHat编写的。

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

enter image description here

请注意，此处的kubelet正在通过CRI与CRI-O对话。 CRI-O正在与cc-runtime（这是Intel透明容器的另一个运行时，是的，符合OCI标准）进行通讯，但是它也可以是kata-runtime。

不要忘记使用容器，它还可以管理所有OCI投诉运行时并使生活变得轻松-确保运行C，但也可以运行kata-runtime，cc-runtime

enter image description here

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

不用说，它可以通过CRI-O或cri-containerd（也称为CRI插件）在Kubernetes上运行。

enter image description here

这真的很酷：top：

库伯奈特先生（以大使为代表）经营的任何满足CRI要求的项目。 现在，我们有几个候选人可以。 -Cri-containerd使集装箱运输做到这一点。 -CRI-O本机执行。 -Dockershim使Docker引擎做到这一点。

现在，上述所有三个家伙都可以管理所有OCI兼容运行时-runC，kata-runtime，cc-runtime，并使生活变得轻松。

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

在这里，我们使用CRI-O进行动作管理，并使符合OCI的kata-runtime和runC的工作变得轻松

enter image description here

我们还有更多的运行时：

  • 铁路车-符合OCI，以锈写
  • 邮袋-阿里巴巴修改后的runC
  • nvidia运行时-nvidia的runC分支

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

答案 2 :(得分：3)

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

  

runc是containerd的组件，container是容器的执行程序。 containerd的作用范围比仅仅执行容器要广泛：下载容器映像，管理存储和网络接口，使用正确的参数调用runc来运行容器。

来自同一来源的

This image很好地描述了这一点。

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

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

[编辑] 我写了更多有关这种术语here

的文章
相关问题
最新问题