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


【编者的话】本文详细介绍了如何在Kubernetes上使用containerd,介绍了Cri-containerd及其架构,当前状态和远期目标。看来容器运行时又多了一种可选方案。

容器运行时是在某个节点上执行容器并且管理容器镜像的软件。如今,最广为人知的容器运行时是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,在2017年9月25号发布了功能完备的v1.0.0-alpha.0版本。使用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的需求匹配见下表:
对比图.jpg

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

Cri-containerd

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

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

架构

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

让我们使用一个示例来说明当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

试一试

多节点集群安装器,以及使用ansible和kubeadm搭建步骤,查看repo链接

在Google Cloud上从头创建一个集群,请看Kubernetes the Hard Way

自定义安装,查看repo链接

在本地VM上使用LinuxKit安装,请看repo链接

下一步

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

  • 稳定性
    • 在多种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- ... inerd。欢迎贡献任何想法,问题,或者解决方案。想要贡献的人可以从开发者开始指南开始。

社区

Cri-containerd是由Kubernetes SIG-Node社区开发和维护的。我们期望听到你的反馈。要加入社区:


原文链接:Containerd Brings More Container Runtime Options for Kubernetes(翻译:崔婧雯)
===========================
译者介绍
崔婧雯,现就职于IBM,高级软件工程师,负责IBM WebSphere业务流程管理软件的系统测试工作。曾就职于VMware从事桌面虚拟化产品的质量保证工作。对虚拟化,中间件技术,业务流程管理有浓厚的兴趣。

0 个评论

要回复文章请先登录注册