Containerd给Kubernetes带来了更多容器运行时的可选方案

崔婧雯 译 分布式实验室 

容器运行时是在某个节点上执行容器并且管理容器镜像的软件。如今，最广为人知的容器运行时是Docker，但是，生态系统内也有一些别的容器运行时，比如rkt，containerd和Ixd。Docker是目前为止在Kubernetes生产环境里使用最多的容器运行时，不过Docker的近亲，containerd，可能将被证明是一种更好的方案。本文介绍在Kubernetes上使用containerd。
Kubernetes 1.5引入了一种内部插件API，名为Container Runtime Interface（CRI），它提供简单的访问接口，去访问不同的容器运行时。CRI让Kubernetes可以使用多种容器运行时，而无需重新编译。理论上，Kubernetes可以使用任意实现了CRI的容器运行时，来管理pod，容器和容器镜像。
在过去的6个月里，来自Google，Docker，IBM，ZTE和ZJU的工程师一起为containerd实现了CRI。该项目称为cri-containerd[1]，在2017年9月25号发布了功能完备的v1.0.0-alpha.0版本[2]。使用cri-containerd，用户可以使用containerd作为底层运行时来运行Kubernetes集群，而无需安装Docker。

Containerd

Containerd是满足OCI规范的核心容器运行时，从设计上就是为了嵌入大型系统的。它提供了要支持执行容器，并且在某个节点上管理镜像所需功能的最小集合。它由Docker Inc公司启动，并且在2017年3月份捐赠给了CNCF。Docker引擎本身是在containerd的早期版本上构建的，并将很快升级到最新版本。Containerd几乎可以称得上是功能完备且稳定的版本，目前可用的是1.0.0-beta.1。
Containerd的范围比Docker小得多，它提供golang的客户端API，更加关注于可嵌入化。更小的范围意味着更小的代码基，更易于维护和支持，和Kubernetes的需求匹配见下表：

总的来说，从技术角度看，Containend是Kubernetes上很好的容器运行时的替代方案。

Cri-containerd

Cri-containerd[3]是：containerd的CRI的一种实现。它在Kubelet和containerd所在的相����,��ʵ同节点上操作。在Kubernetes和containerd之间，cri-containerd处理来自Kubelet的所有CRI服务请求，并且使用containerd来管理容器和容器镜像。Cri-containerd管理这些服务请求，部分是通过在containerd的服务请求上添加足够的额外信息来支持CRI的要求。

和当前的Docker的CRI实现（dockershim）相比，cri-containerd去掉了stack里的额外hop，让stack更为稳定和高效。

架构

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

让我们使用一个示例来说明当Kubelet创建一个但容器pod时，Cri-containerd是如何工作的：

1. Kubelet调用Cri-containerd，通过CRI运行时服务API，来创建pod；

2. Cri-containerd使用containerd创建并且启动一个特定的pause容器（沙箱容器），并且将该容器放到pod的cgroup和命名空间里（简化起见跳过这里的详细步骤）；

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的cgroup和命名空间里，并且启动pod的全新的应用程序容器。

这些步骤之后，一个pod及其对应的应用程序容器就被创建了出来，并运行着了。

状态

Cri-containerd v1.0.0-alpha.0在2017年9月25号发布。
它特性完备。支持所有Kubernetes特性。
所有CRI验证测试都已经通过了。（CRI验证是验证某一CRI实现是否满足Kubernetes所需的所有要求的测试框架）
所有常规的节点e2e测试也都通过了。（Kubernetes测试框架用来测试Kubernetes节点级别的功能的，比如管理pod，mount卷等等。）
要想了解v1.0.0-alpha.0版本的更多信息，请查看项目repository[2]。

试一试

多节点集群安装器，以及使用ansible和kubeadm搭建步骤，查看repo链接[4]。
在Google Cloud上从头创建一个集群，请看Kubernetes the Hard Way[5]。
自定义安装，查看repo链接[6]。
在本地VM上使用LinuxKit安装，请看repo链接[7]。

下一步

接下来会关注于稳定性和可用性上的改进。
稳定性

• 在多种OS发行版，比如Ubuntu，COS（容器优化OS）等上，在Kubernetes测试基础架构上搭建完整的Kubernetes集成测试。

• 积极解决所有测试失败以及其他用户汇报的问题。

可用性

• 改进crictl的用户体验。Crictl是所有CRI容器运行时的便携的命令行工具。这里的目标是让它更易于调试和开发。

• 将Cri-containerd和kuber-up.sh集成，帮助用户使用Cri-containerd和containerd搭建满足生产环境质量要求的Kubernetes集群。

计划在2017年末发布v1.0.0-beta.0版本。

贡献

Cri-containerd是Kubernetes的孵化项目，位于https://github.com/kubernetes-incubator/cri-containerd。欢迎贡献任何想法，问题，或者解决方案。想要贡献的人可以从开发者开始指南[8]开始。
相关链接：

1. https://github.com/kubernetes-incubator/cri-containerd

2. https://github.com/kubernetes-incubator/cri-containerd/releases/tag/v1.0.0-alpha.0

3. https://github.com/kubernetes-incubator/cri-containerd

4. https://github.com/kubernetes-incubator/cri-containerd/blob/master/contrib/ansible/README.md

5. https://github.com/kelseyhightower/kubernetes-the-hard-way

6. https://github.com/kubernetes-incubator/cri-containerd/blob/master/docs/installation.md

7. https://github.com/linuxkit/linuxkit/tree/master/projects/kubernetes

8. https://github.com/kubernetes-incubator/cri-containerd#getting-started-for-developers

原文链接：http://blog.kubernetes.io/2017/11/containerd-container-runtime-options-kubernetes.html