标签：容器 1.1 Kubernetes Containerd GA containerd Docker CRI
Sam Zhang 译 分布式实验室
在之前的博客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
相关链接：
https://kubernetes.io/blog/2017/11/containerd-container-runtime-options-kubernetes
https://github.com/containerd/containerd/releases/tag/v1.1.0
https://k8s-testgrid.appspot.com/sig-node-containerd
https://github.com/kubernetes/community/blob/master/contributors/devel/e2e-node-tests.md
http://node-perf-dash.k8s.io/
https://github.com/kubernetes-incubator/cri-tools
https://github.com/kubernetes-incubator/cri-tools/releases/tag/v1.0.0-beta.1
https://www.ianlewis.org/en/almighty-pause-container
标签：容器,1.1,Kubernetes,Containerd,GA,containerd,Docker,CRI 来源： https://blog.51cto.com/u_15127630/2774502
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。