容器与runC的比较

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

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

containerd是一个容器运行时,可以管理一个完整的容器生命周期 - 从映像传输/存储到容器执行,监督和网络.

container-shim handle无头容器,意思是一旦runc初始化容器,它就会将容器放到容器垫片上,垫片就像一些中间人一样.

runc是轻量级通用运行时容器,遵循OCI规范.根据OCI规范,containerc用于生成和运行容器.它也是libcontainer的重新包装.

grpc用于containerd和docker -engine之间的通信.

OCI维护运行时和映像的OCI规范.当前的docker版本支持OCI映像和运行时规范.

更多链接:

打开容器规格

一个漂亮的dockercon 2016年演示文稿

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分支

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