Kubernetes Containerd集成进入GA阶段

在之前的博客Containerd给Kubernetes带来更多的容器运行选项[1]，我们介绍了Kubernetes containerd integration的内部测试版。经历了6个月的开发，正式版推出了！现在，你可以在生产环境的Kubernetes集群使用containerd 1.1[2]作为容器运行时组件！
Containerd 1.1运行在Kubernetes 1.10或以上版本，支持所有Kubernetes特性。在Google云上的Kubernetes测试设施，containerd integration的功能已经和Docker integration旗鼓相当。（见：test dashboard[3]）。我们很乐见于containerd迅速成长到这个重要的里程碑。阿里云从第一天开始就积极地使用containerd，简单和注重稳健，使其成为完美地容器引擎，运行在我们的无服务器化Kubernetes产品中，提供了高标准的表现和稳定。毫无疑问，containerd将成为容器时代的核心引擎并且继续驱动进一步的创新。
——Xinwei，阿里巴巴工程师架构提升

Kubernetes的containerd架构进化了两次。每次进化使整个体系更加稳定和有效率。
Containerd 1.0 – CRI-Containerd（已完成）

在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 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[4]的组件Kubernetes node performance benchmark生成。大部分containerd基准数据可以在node performance dashboard[5]公开访问。
Pod启动延迟
下图的是105个Pod批量启动的数据。结果显示使用containerd 1.1比Docker 18.03 CE更加快。（数字越低越好）。

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内存使用率。

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[6]，目前版本是v1.0.0-beta.1[7]。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容器和应用容器显示在一起：

Pause容器[8]是一个Pod的实行细节，每个Pod都有一个Pause容器，因此没有必要被列出。
恰恰相反，Crictl是为Kubernetes设计的。针对pods和容器有不同的命令组。如，crictl pods列出Pod信息，crictl ps只列出应用容器的信息。所有的信息都被格式化成列表。

另一个例子，crictl pods有一个-namespace选项，依据Kubernetes中特定的namespaces来过滤pods。

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

• 文档：https://github.com/containerd/cri/blob/master/docs/crictl.md

• Demo视频：https://asciinema.org/a/179047

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使用：

既然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/containerd/releases/tag/v1.1.0
相关链接：

1. https://kubernetes.io/blog/2017/11/containerd-container-runtime-options-kubernetes

2. https://github.com/containerd/containerd/releases/tag/v1.1.0

3. https://k8s-testgrid.appspot.com/sig-node-containerd

4. https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-node-tests.md

5. http://node-perf-dash.k8s.io/

6. https://github.com/kubernetes-incubator/cri-tools

7. https://github.com/kubernetes-incubator/cri-tools/releases/tag/v1.0.0-beta.1

8. https://www.ianlewis.org/en/almighty-pause-container

原文链接：https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/

Kubernetes入门与进阶实战培训

本次培训内容包括：Docker基础、容器技术、Docker镜像、数据共享与持久化、Docker三驾马车、Docker实践、Kubernetes基础、Pod基础与进阶、常用对象操作、服务发现、Helm、Kubernetes核心组件原理分析、Kubernetes服务质量保证、调度详解与应用场景、网络、基于Kubernetes的CI/CD、基于Kubernetes的配置管理等， 点击了解具体培训内容。

6月22日正式上课，点击阅读原文链接即可报名。