66

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

4

3 回答 3

104

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

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

运行C，容器D

更多链接：

于 2017-01-14T03:36:20.853 回答
44

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

在此处输入图像描述

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

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

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

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

请注意，运行时必须符合 OCI（就像 runC 一样），也就是说，它们必须向 containerd 之类的管理器公开一个固定的 API，以便它们（containerd）可以让它们（runC）的生活变得轻松（并要求它们停止/启动容器）

在此处输入图像描述

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

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

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

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

containerd 不支持 CRI，但 cri-containerd 是 containerd 周围的 shim 支持。所以，如果你想用 Kubernetes 运行 containerd，你必须使用 cri-containerd（这也是 Kubernetes 的默认运行时）。cri-containerd 最近重命名为 CRI 插件。

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

在此处输入图像描述

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

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

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

这就是我们有 CRI-O 的原因。它就像 containerd，但它实现了 CRI。CRI-O 需要一个容器运行时来运行图像。它将管理该运行时并使生活变得轻松，但它需要一个运行时。它将采用任何符合 OCI 的运行时。所以，很自然，~kata-runtime~ 是 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（这是英特尔透明容器的另一个运行时，是的，符合 OCI）进行对话，但它也可能是 kata-runtime。

不要忘记 containerd，它也可以管理所有 OCI 投诉运行时并使生活变得轻松 - 当然可以运行 C，但也可以使用 kata-runtime、cc-runtime

在此处输入图像描述

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

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

在此处输入图像描述

这真的很酷 :top:

Kubernetes，由它的大使代表，Kubelet 先生运行任何满足 CRI 的东西。现在，我们有几个候选人可以。- Cri-containerd 让 containerd 做到这一点。- CRI-O 本身就是这样做的。- Dockershim 让 docker 引擎做到这一点。

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

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

在这里，我们有 CRI-O 在行动中管理和简化 OCI 兼容的 kata-runtime 和 runC 的工作

在此处输入图像描述

我们还有一些运行时：

  • railcar - OCI 兼容，用 rust 编写
  • Pouch——阿里巴巴修改后的runC
  • nvidia runtime - nvidia 的 runC 分支

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

于 2018-08-11T18:45:10.737 回答
5

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

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

来自同一来源的这张图片很好地描述了这一点。

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

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

[编辑] 我在这里写了更多关于这个术语的信息

于 2018-07-26T20:02:45.783 回答