containerd与runC的比较

Question

这两个是怎么比较的？据我所知，runC是一个容器的运行时环境。这意味着该组件提供了运行容器所需的环境。那么集装箱在这里的作用是什么呢？如果它完成了其余的工作(网络、卷管理等)，那么Docker引擎的作用是什么？那containerd-shim呢？基本上，我正在尝试理解每个组件的作用。

Answer 1

我将给你一个高层次的概述，让你入门：

• containerd是一个容器运行时，它可以管理一个完整的容器生命周期-从图像传输/存储到容器执行，监督和networking.
• container-shim处理无头容器，这意味着一旦runc初始化容器，它就会退出，将容器交给容器-填充程序，它的作用就像一些middleman.
• runc是轻量级通用运行时容器，遵守OCI规范。runc由containerd使用，用于根据OCI规范生成和运行容器。它也是对用于containerd和docker-engine.
• OCI之间通信的libcontainer.
• grpc的重新打包，维护了运行时和镜像的OCI规范。当前的docker版本支持OCI镜像和运行时规范。

​

​

更多链接：

• Open Container Specification
• A nice dockercon 2016 presentation

Answer 2

Docker引擎就是它的全部，它是一个使用户能够运行容器的巨石。然后，它被分解成单独的组件。它被分解为：- docker engine - containerd runc

​

​

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

containerd负责设置网络、图像传输/存储等工作，它负责整个容器运行时(这意味着，它管理并简化了runC的工作，这就是实际的容器运行时)。与Docker守护进程不同，它有一个精简的功能集；例如，不支持图像下载。

Docker engine本身只是做一些高层次的事情，比如接受用户命令，从docker注册表下载图像等。它将大量的内容卸载到容器中。

“Docker守护程序将映像准备为开放容器映像( OCI )包，并向容器d发出API调用以启动OCI包。然后，容器d使用runC启动容器。”

注意，运行时必须是OCI兼容的(就像runC一样)，也就是说，它们必须向像containerd这样的管理器公开一个固定的API，这样它们(Containerd)就可以简化它们(RunC)的工作(并要求它们停止/启动容器)。

​

​

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

所以，就是这样。现在，让我们向mix - Kubernetes添加另一个组件(和另一个接口

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

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

containerd不支持CRI，但是cri-containerd支持。因此，如果你想在Kubernetes中运行containerd，你必须使用cri-containerd (这也是Kubernetes的默认运行时)。cri-containerd最近被重命名为CRI Plugin。

如果你想把docker引擎也加入进来，你可以这么做。使用dockershim，它会将CRI填充程序添加到docker引擎。

​

​

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

现在我们知道rkt满足CRI，cri-containerd (也就是CRI插件)也满足CRI。

注意containerd在这里做了什么。它不是运行时，它是容器运行时runC的管理器。它只是管理图片的下载，存储等等，它甚至不能满足CRI的要求。

这就是我们有CRI-O的原因。它就像容器一样，但它实现了CRI。CRI-O需要一个容器运行时来运行镜像。它将管理并简化运行时，但它需要一个运行时。它将使用任何符合OCI的运行时。所以，很自然，~kata- runC ~是兼容CRI-O的，runC也是兼容CRI-O的。

使用Kubernetes很简单，将Kubernetes指向CRI-O作为容器运行时。(是的，CRI-O，但是CRI-O和实际的容器运行时是。Kubernetes指的是容器运行时这对幸福的情侣)。

就像containerd有docker使它真正可用，并且为了管理和简化containerd的生活，CRI-O需要有人来负责图像管理-它有buildah，umochi等。

crun是另一个运行时，它符合OCI标准，并用C编写。它是由RedHat编写的。

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

​

​

注意，在这里，kubelet通过CRI与CRI-O通信。CRI-O正在与cc-runtime对话(这是Intel的clear containers的另一个运行时，是的，符合OCI )，但它也可能是kata-运行时。

不要忘记containerd，它也可以管理和简化所有OCI抱怨的运行时--当然，还有kata- runC，cc-runtime

​

​

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

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

​

​

这真的很酷:top：

Kubernetes在这里由它的大使代表，Kubelet先生管理任何满足CRI的事情。现在，我们有几个候选人可以。- Cri-containerd让containerd执行此操作。- CRI-O在本地执行此操作。- Dockershim让docker引擎做这件事。

现在，上面的3个人都可以管理和简化所有兼容OCI的运行时-- runC，kata-runtime，cc-runtime。

我们还有frakti，它满足CRI，如rkt，但不满足OCI，并与它自己的容器运行时捆绑在一起。

在这里，我们使用CRI-O来管理和简化兼容OCI的kata- runC和runC的工作。

​

​

我们还有更多的运行时：

• railcar -符合OCI，使用rust
• 包编写-阿里巴巴修改后的runC
• nvidia运行时-nvidia的runC

分支

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

Answer 3

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

containerd runc是

的一个组件，containerd是容器的执行器。containerd不仅仅是执行容器:下载容器镜像，管理存储和网络接口，使用正确的参数调用runc来运行容器。

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

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

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

编辑我写了更多关于这个临时学here的内容