Kubernetes Containerd集成进入GA阶段


【编辑的话】containerd 1.1的发布,将CRI plugin整合进了containerd。简化了结构,提高了集群的性能和稳定。

在之前的博客Containerd给Kubernetes带来更多的容器运行选项,我们介绍了Kubernetes containerd integration的内部测试版。经历了6个月的开发,正式版推出了!现在,你可以在生产环境的Kubernetes集群使用containerd 1.1作为容器运行时组件!

Containerd 1.1运行在Kubernetes 1.10或以上版本,支持所有Kubernetes特性。在Google云上的Kubernetes测试设施,containerd integration的功能已经和Docker integration旗鼓相当。(见:test dashboard)。


我们很乐见于containerd迅速成长到这个重要的里程碑。阿里云从第一天开始就积极地使用containerd,简单和注重稳健,使其成为完美地容器引擎,运行在我们的无服务器化Kubernetes产品中,提供了高标准的表现和稳定。毫无疑问,containerd将成为容器时代的核心引擎并且继续驱动进一步的创新。
-Xinwei,阿里巴巴工程师*

架构提升

Kubernetes的containerd架构进化了两次。每次进化使整个体系更加稳定和有效率。

Containerd 1.0 – CRI-Containerd(已完成)

cri-containerd.png

在containerd 1.0中,Kubelet和containerd之间的操作使由一个叫做cri-containerd的进程来完成的。Cri-containerd处理来自Kubelet的容器运行界面(CRI)服务请求,并且使用containerd来管理容器和相应的容器镜像。相比较于Docker CRI方案(dockershim),淘汰了体系中一个额外的步骤。

当然,cri-containerd和containerd 1.0仍然是通过grpc连接的两个不同的进程。额外的进程使整个流程复杂,用户不容易理解和部署,带来不必要的沟通成本。

Containerd 1.1 – CRI Plugin(当前版本)

containerd.png

在containerd 1.1中,cri-containerd进程被重构成为containerd CRI plugin。CRI plugin被构造进containerd 1.1,并且默认启用。不同于cri-containerd,CRI plugin直接通过函数调用来和containerd交互。这个新架构使整合更加稳定和有效,并淘汰了额外的grpc hop。用户可以直接在Kubernetes使用containerd 1.1。Cri-containerd进程不再需要了。

性能表现

提高性能是containerd 1.1发布的主要关注指标之一。性能优化主要包括Pod启动延迟和进程资源的占用。

下面是containerd 1.1 and Docker 18.03 CE的比较结果。Containerd 1.1使用内置的CRI plugin;Docker 18.03 CE使用dockershim。

结果是由Kubernetes node e2e test的组件Kubernetes node performance benchmark生成。大部分containerd基准数据可以在node performance dashboard公开访问。

Pod启动延迟

下图的是105个Pod批量启动的数据。结果显示使用containerd 1.1比Docker 18.03 CE更加快。(数字越低越好)。
latency.png

CPU和内存

稳定情况下的105个Pod,containerd 1.1比Docker 18.03 dockershim消耗更少的CPU和内存。Node中Pod数量的不同会使结果也不同,之所以选择105个Pod是因为这是每个Node的最大Pod数量。

下图的数据显示,和Docker 18.03 dockershim比较,containerd 1.1降低了30.80%的Kubelet的CPU使用率,降低了68.13%的容器运行CPU使用率,降低了11.30%Kubelet resident set size(RSS)内存使用率,降低了12.78%容器运行RSS内存使用率。
cpu.png

memory.png

Crictl

容器运行命令行界面(CLI)是一个有用的系统和应用故障排除工具。使用Docker作为Kubernetes的容器运行时,系统管理员有时登陆到Kubernetes node去执行Docker命令来搜集系统和应用的信息。例如,使用docker ps和docker inspect检查应用进程的状态,使用docker images列出node上的镜像,以及使用docker info验证容器运行配置等。

对于containerd和所有其他CRI兼容容器运行,如dockershim,我们建议使用crictl作为Docker CLI的替代来为Kubernetes nodes上的Pod,容器和容器镜像做故障排除。

Crictl是一个提供了和Docker CLI类似经验来为Kubernetes node故障排除的工具。始终如一地运行在所有CRI兼容容器运行。托管在kubernetes-incubator/cri-tools,目前版本是v1.0.0-beta.1。Crictl被设计成类似于Docker CLI为用户提供更好的过渡体验,但不是完全一样。下面将解释一些重要的区别。

有限的范围:Crictl是一个故障排除工具

Crictl的适用范围是有限的故障排除工具,并非是Docker或者kubectl的替代品。Docker的CLI提供了一系列丰富的命令,使其成为非常有用的开发工具。但是它不是最适合作为Kubernetes nodes的故障排除工具。一些Docker的命令,如docker network和docker build并不适用于Kubernetes;甚至有些命令会破坏Kubernetes系统,如docker rename。Crictl提供刚刚适合的命令来为生产环境中的node故障排除。

Kubernetes为导向

Crictl提供对Kubernetes更友好的容器界面。Docker CLI缺少核心的Kubernetes概念,如pod和namespace,因此它不能提供清晰的容器和pods的信息。比如,docker ps显示有些混乱,长的容器名字,Pause容器和应用容器显示在一起:
docker-ps.png

Pause容器是一个Pod的实行细节,每个Pod都有一个Pause容器,因此没有必要被列出。

恰恰相反,Crictl是为Kubernetes设计的。针对pods和容器有不同的命令组。如,crictl pods列出Pod信息,crictl ps只列出应用容器的信息。所有的信息都被格式化成列表。
crictl-pods.png

crictl-ps.png

另一个例子,crictl pods有一个-namespqce选项,依据Kubernetes中特定的namespaces来过滤pods。
crictl-pods-filter.png

想要更多关于如何在容器中使用Crictl:


Docker Engine怎么办?

“切换到containerd是否意味着不再使用Docker Engine?”我们很多次听到这个问题,答案是NO。

Docker Engine是构建在containerd之上的。下一个Docker社区版(Docker CE)将使用containerd 1.1。当然,默认内置和启用了CRI plugin。这意味着有特定需求的Docker用户可以选择继续使用Docker Engine,与此同时,也能够用内置的,同时也被Docker Engine使用的containerd来配置Kubernetes。下图说明了containerd同时被Docker Engine和Kubelet使用:
docker-ce.png

既然containerd同时被Docker Engine和Kubelet使用,那这意味着用户选择使用了containerd后,不仅可以得到新的Kubernetes特性,性能和稳定的提升,也将同时为了保留使用Docker Engine的选项以便满足其他的情况。

Containerd namespace机制是被用于保证Kubelet和Docker Engine不会看到和进入对方的建立的容器和镜像。这是为了不让二者互相干扰。也意味着:
  • 用户将不能使用docker ps命令查看到Kubernetes创建的容器。请使用crictl ps替代。反之亦然。用户不能使用crictl ps命令查看到Docker CLI创建的融洽。crictl create和crictl runp命令只用于故障排除。不建议手动在生产环境下的nodes上使用crictl on来启动pod或容器。
  • 用户不能使用docker images命令查看到Kubernetes拉取的镜像。请使用crictl images命令替代。反之亦然,Kubernetes看不到docker pull,docker load或docker build创建的镜像。请使用crictl pull命令替代,如果你需要载入一个镜像请使用ctr cri load。


Summary

  • Containerd 1.1原生支持CRI,Kubernetes直接调用。
  • Containerd 1.1适用于生产环境。
  • Containerd 1.1就启动延迟和系统资源利用率而言,有好的表现。
  • Crictl是CLI工具,containerd通过它来和其他CRI兼容的容器运行交互,从而为node做故障排除。
  • 下一个稳定版本的Docker CE将包含containerd 1.1,。用户选择继续使用Docker Engine,与此同时,也能够用内置的,同时也被Docker Engine使用的containerd来配置Kubernetes。


我们这里感谢所有来自Google,IBM,Docker,ZTE,ZJU和很多其他独立开发者的贡献!

详细的containerd 1.1更新列表,请点击下面的连接:
https://github.com/containerd/ ... 1.1.0

体验一下

使用containerd作为容器运行来建立Kubernetes集群:


贡献

Containerd CRI插件包含在是一个开源的github项目containerd里https://github.com/containerd/cri。欢迎任何关于想法,故障,或者修复的贡献。请从getting started guide for developers开始。

社区

这个项目的开发和维护是由 Kubernetes SIG-Node 社区成员和 Containerd 社区联合负责的。我们希望能听到你的反馈,加入集群:


原文链接:Kubernetes Containerd Integration正式版发布 (翻译:Sam)

0 个评论

要回复文章请先登录注册