本文发布时间超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已不正确。

Containerd 为 Kubernetes 带来更多容器运行时选项

作者：Lantao Liu（Google），Mike Brown（IBM） |

更新：Kubernetes 通过 dockershim 对 Docker 的支持现在已弃用。有关更多信息，请阅读弃用通知。您也可以通过专门的GitHub issue来讨论弃用问题。

容器运行时是一种在节点上执行容器并管理容器镜像的软件。今天，最广为人知的容器运行时是Docker，但生态系统中还有其他容器运行时，例如rkt、containerd和lxd。Docker 是迄今为止 Kubernetes 生产环境中最常用的容器运行时，但 Docker 的小型后代 containerd 可能会被证明是一个更好的选择。这篇文章描述了如何将 containerd 与 Kubernetes 一起使用。

Kubernetes 1.5 引入了一个名为容器运行时接口 (CRI)的内部插件 API，以方便访问不同的容器运行时。CRI 使 Kubernetes 能够使用各种容器运行时，而无需重新编译。理论上，Kubernetes 可以使用任何实现 CRI 的容器运行时来管理 Pod、容器和容器镜像。

在过去的 6 个月中，来自 Google、Docker、IBM、ZTE 和 ZJU 的工程师一直致力于为 containerd 实现 CRI。该项目名为cri-containerd，于 2017 年 9 月 25 日发布了其功能完整的 v1.0.0-alpha.0 版本。借助 cri-containerd，用户可以在不安装 Docker 的情况下，使用 containerd 作为底层运行时运行 Kubernetes 集群。

containerd

Containerd 是一种OCI兼容的核心容器运行时，旨在嵌入到更大的系统中。它提供了执行容器和管理节点上镜像的最少功能集。它由 Docker Inc. 发起，并于 2017 年 3 月捐赠给 CNCF。Docker 引擎本身是基于早期版本的 containerd 构建的，很快将更新到最新版本。Containerd 接近功能完整的稳定版本，1.0.0-beta.1 版本现在可用。

Containerd 的范围比 Docker 小得多，它提供了一个 golang 客户端 API，并且更侧重于可嵌入性。较小的范围导致更小的代码库，更容易维护和支持，这符合 Kubernetes 的要求，如下表所示

Containerd 范围（包含/排除）Kubernetes 要求
容器生命周期管理包含容器创建/启动/停止/删除/列表/检查 (✔️)
镜像管理包含拉取/列表/检查 (✔️)
网络排除，没有具体的网络解决方案。用户可以设置网络命名空间并将容器放入其中。Kubernetes 网络处理的是 Pod，而不是容器，因此容器运行时不应提供不满足要求的复杂网络解决方案。 (✔️)
卷排除，没有卷管理。用户可以设置主机路径，并将其挂载到容器中。Kubernetes 管理卷。容器运行时不应提供可能与 Kubernetes 冲突的内部卷管理。 (✔️)
持久容器日志记录排除，没有持久容器日志。容器 STDIO 以 FIFO 的形式提供，可以根据需要重定向/装饰。Kubernetes 对持久容器日志有特定的要求，例如格式和路径等。容器运行时不应持久化不可管理的容器日志。 (✔️)
指标包含。Containerd 提供容器和快照指标作为 API 的一部分。Kubernetes 期望容器运行时提供容器指标（CPU、内存、可写层大小等）和镜像文件系统使用情况（磁盘、inode 使用情况等）。 (✔️)
总的来说，从技术角度来看，containerd 是 Kubernetes 的一个非常好的替代容器运行时。

cri-containerd

Cri-containerd 恰恰是：containerd 的 CRI 实现。它与 Kubelet 和 containerd 在同一个节点上运行。Cri-containerd 位于 Kubernetes 和 containerd 之间，处理来自 Kubelet 的所有 CRI 服务请求，并使用 containerd 来管理容器和容器镜像。Cri-containerd 通过形成 containerd 服务请求来部分管理这些服务请求，同时添加足够多的额外功能来支持 CRI 要求。

与当前的 Docker CRI 实现（dockershim）相比，cri-containerd 消除了堆栈中的额外跃点，使堆栈更加稳定和高效。

架构

Cri-containerd 使用 containerd 来管理完整的容器生命周期和所有容器镜像。如下所示，cri-containerd 还通过 CNI（另一个 CNCF 项目）管理 Pod 网络。

让我们用一个示例来演示 cri-containerd 在 Kubelet 创建单容器 Pod 时的工作方式

  1. Kubelet 通过 CRI 运行时服务 API 调用 cri-containerd 来创建 Pod；
  2. cri-containerd 使用 containerd 创建并启动一个特殊的暂停容器（沙箱容器），并将该容器放入 Pod 的 cgroups 和命名空间中（为简洁起见省略步骤）；
  3. cri-containerd 使用 CNI 配置 Pod 的网络命名空间；
  4. Kubelet 随后通过 CRI 镜像服务 API 调用 cri-containerd 来拉取应用程序容器镜像；
  5. 如果节点上不存在该镜像，cri-containerd 将进一步使用 containerd 来拉取镜像；
  6. 然后，Kubelet 通过 CRI 运行时服务 API 调用 cri-containerd，以使用拉取的容器镜像在 Pod 内创建并启动应用程序容器；
  7. cri-containerd 最终调用 containerd 来创建应用程序容器，将其放入 Pod 的 cgroups 和命名空间中，然后启动 Pod 的新应用程序容器。完成这些步骤后，将创建并运行一个 Pod 及其对应的应用程序容器。

状态

Cri-containerd v1.0.0-alpha.0 于 2017 年 9 月 25 日发布。

它功能完备。支持所有 Kubernetes 功能。

所有CRI 验证测试均已通过。（CRI 验证是一个测试框架，用于验证 CRI 实现是否满足 Kubernetes 期望的所有要求。）

所有常规节点 e2e 测试均已通过。（Kubernetes 测试框架，用于测试 Kubernetes 节点级功能，例如管理 Pod、挂载卷等。）

要了解有关 v1.0.0-alpha.0 版本的更多信息，请参阅项目存储库。

试用一下

有关使用 ansible 和 kubeadm 的多节点集群安装程序和启动步骤，请参阅此存储库链接。

有关从头开始在 Google Cloud 上创建集群，请参阅Kubernetes The Hard Way。

有关从发布 tarball 进行自定义安装，请参阅此存储库链接。

有关在本地 VM 上使用 LinuxKit 进行安装，请参阅此存储库链接。

后续步骤

我们的下一步重点是稳定性和可用性改进。

  • 稳定性

    • 在 Kubernetes 测试基础架构中，针对各种操作系统发行版（例如 Ubuntu、COS (容器优化操作系统) 等）设置一套完整的 Kubernetes 集成测试。
    • 积极修复用户报告的任何测试失败和其他问题。

  • 可用性

    • 改善 crictl 的用户体验。Crictl 是一个用于所有 CRI 容器运行时的便携式命令行工具。这里的目标是使其易于在调试和开发场景中使用。
    • 将 cri-containerd 与 kube-up.sh 集成，以帮助用户使用 cri-containerd 和 containerd 启动生产质量的 Kubernetes 集群。
    • 改进我们针对用户和管理员的文档。

我们计划在 2017 年底之前发布 v1.0.0-beta.0。

贡献

Cri-containerd 是一个 Kubernetes 孵化项目，位于 https://github.com/kubernetes-incubator/cri-containerd。欢迎就想法、问题和/或修复方面做出任何贡献。开发人员入门指南是贡献者的一个很好的起点。

社区

Cri-containerd 由 Kubernetes SIG-Node 社区开发和维护。我们很乐意听取您的反馈。要加入社区