注意事项 佩雷夫 ：我们已经为Kubernetes写了不止一次有关容器化和其他运行时的文章。 该新出版物是对最近发布的关于集装箱开发的一个重要里程碑的公告的翻译，该公告已发布在Kubernetes项目的官方博客上。 这些文字是由Google和IBM的员工编写的，它们（当然，还有Docker Inc.）也为改善容器化做出了巨大贡献。在博客的较早部分（在注记着
Containered为Kubernetes带来了更多的容器运行时选项）中，我们介绍了
Containerd与Kubernetes集成的Alpha版本。 在接下来的6个月的开发过程中，集成已经公开可用！ 这意味着现在您可以将
容器化的1.1用作生产中Kubernetes集群中容器的运行时。
Containerd 1.1与Kubernetes 1.10及更高版本一起使用，支持所有Kubernetes功能。 在Kubernetes测试基础架构中，Google Cloud Platform上的容器集成测试的覆盖范围已与与Docker的集成相同（请参阅
测试仪表板 ）。
“我们很高兴看到集装箱运输迅速达到这一重要里程碑。 在阿里云，我们从一开始就开始积极使用容器化，并且由于其对简单性和可靠性的重视，使得容器化成为我们无服务器Kubernetes产品中的默认容器引擎，这对性能和稳定性提出了很高的要求。 毫无疑问，集装箱运输将成为集装箱时代的主要动力，并带动创新的发展。” -阿里云的专职工程师Xinwei
架构上的改进
与Kubernetes集成容器的架构发生了两次变化。 它的每个进化步骤均稳定并提高了堆叠效率。
容器式1.0-CRI容器（已存在）
在containerd 1.0中，
Kubelet和containerd之间的交互需要cri-containerd守护进程
（我们在本文结尾处写了它- 大约Transl。 ） 。 该守护程序处理来自
Kubelet的对
容器运行时接口（CRI）的
请求，并使用容器来正确管理容器和容器映像。 与Docker CRI实现（
dockershim ）相比，此方法消除了堆栈中的另一个链接-
请参见上图 。
但是，cri-containerd和containerd 1.0是通过GRPC进行交互的两个单独的守护程序。 该捆绑软件中的附加守护程序使用户在了解设备和部署过程中都变得很困难，并且还产生了不必要的交互开销。
容器1.1-CRI插件（当前版本）
在容器1.1中，cri-containerd守护进程已重做到容器CRI插件中。 此插件内置在容器1.1中，默认情况下启用。 与cri-containerd不同，该插件通过直接调用必要的功能与容器交互。 新架构使集成更加稳定和高效，从堆栈中消除了另一个链接（GRPC）。 现在，可以在Kubernetes中直接使用容器化的1.1，并且不再需要cri-containerd守护程序。
性能表现
容器1.1的主要目标之一是提高性能。 在启动时间和守护程序使用的资源方面进行了优化。
以下结果是对容器化1.1和Docker 18.03 CE的比较。 集成容器1.1使用内置的CRI插件，而Docker 18.03 CE的集成与dockershim一起使用。 结果是使用Kubernetes节点性能基准生成的，该基准是
K8s节点的
e2e测试的一部分 。 大多数比较数据可在
节点性能仪表板上公开获得。
炉床启动延迟
105个pod批处理启动基准测试的结果表明，容器1.1集成与使用dockershim的Docker 18.03 CE相比，启动pod的延迟更少（越小越好）。
CPU和内存
在空闲状态下，具有105个炉膛的容器式1.1集成比与dockershim的Docker 18.03 CE集成消耗更少的处理器和内存。 结果可能会有所不同，具体取决于节点上启动的炉床数量-选择了105炉床数量，因为 现在，默认值是节点上自定义炉床的最大值。
从下图可以看出，容器式1.1与
Kubelet的集成消耗的CPU减少了30.89％，RSS内存（驻留集大小）减少了11.30％，容器运行时消耗的RSS内存也减少了12.78％ 。
译者的加法
值得关注的是，另一个替代解决方案CRI-O正在继续开发。 特别是在这些天的2018年日本开源峰会上 ，NTT的一名员工发表了一份报告 ，对现有容器的可执行环境进行了广泛的比较。 这是他比较性能的一张幻灯片：
关键
容器运行时控制台界面（CLI）是用于识别系统和应用程序中问题的有用工具。 当在Kubernetes中将Docker用作容器环境时，系统管理员有时会去Kubernetes站点运行Docker命令并收集有关系统和/或应用程序的信息。 例如，他们可以使用
docker ps和
docker inspect检查进程的状态，使用
docker images获取节点上图像的列表，使用
docker info获取容器的运行时配置，等等。
对于与Dockershim等容器化和所有其他CRI兼容的环境，我们建议使用
crictl作为Docker控制台命令的CLI替代方法，以分析Kubernetes节点上托管的Pod，容器和容器映像上的问题。
crictl是一种实用程序，提供与Docker CLI类似的功能，并且在与CRI兼容的容器的所有运行时环境中
均能很好地工作。 可以在
kubernetes-incubator / cri-tools存储库中找到它； 当前版本是
cri-tools v1.11.0 （该版本已在3天前针对当前发行版进行了修复，而不是原始文章中指出的v1.0.0-beta.1 ， 大约是transl。 ） 。 尽管
crictl实用程序的设计类似于Docker CLI，为用户提供了一个简单的过渡，但它并不是完整的副本。 以下是一些重要的区别。
限制使用：crictl是故障排除工具
crictl不能替代docker或
kubectl -它的使用仅限于问题识别和分析的范围。 Docker控制台界面提供了丰富的命令集，使其成为非常有用的开发工具。 但是，这不是在Kubernetes节点上进行故障排除的最佳选择。 某些Docker命令（例如docker
docker network和docker
docker build ）对Kubernetes无效，而某些（例如docker named）可以破坏一切。
crictl的目的是提供足够的命令来识别在生产环境中可以安全使用的节点上的问题。
Kubernetes重点
crictl在Kubernetes世界中提供了更易理解的容器视图。 Docker控制台界面无法与基本的Kubernetes概念一起使用，例如在（pod）和命名空间（
namespace ）下，这阻止了容器和炉膛的可视化表示
（这个问题的重要性是真实的，在监控环境中已经存在，我们最近在本报告中谈到了- 注意。perev。 ） 一个这样的示例是
docker ps显示了晦涩的Docker容器的长名称，暂停容器列表以及应用程序容器：
但是，
暂停容器是炉床实现的一部分，其中每个炉床都使用一个这样的容器。 当显示属于炉膛的容器时，不应显示它们。
相比之下，crictl是为Kubernetes创建的。 该实用程序为炉膛和容器提供了不同的命令集。 例如，
crictl pods显示有关
crictl pods信息，而
crictl ps仅显示有关应用程序容器的信息。 所有数据都在表格视图中格式化：
另一个示例-在
crictl pods有一个参数
--namespace ，它允许通过Kubernetes中定义的名称空间过滤pod：
有关如何在容器中使用crictl的更多信息，请参见此处：
但是Docker引擎呢？
我们经常听到以下问题：“切换到容器意味着我不能再使用Docker引擎了吗？”，对此的简短回答是“否”。
Docker Engine是基于容器构建的。 下一版本的Docker Community Edition（Docker CE）将使用容器化版本1.1。 因此，它将具有内置的默认CRI插件并启用。 这意味着用户将有机会继续在其他典型场景下使用Docker引擎，并且能够配置Kubernetes以使用Docker引擎随附的基础容器，并且该容器在同一主机上同时被Docker引擎使用。 看一下下面的架构图，展示Docker Engine和
Kubelet如何使用相同的容器：
由于
Kubelet和Docker Engine都使用了
containerd ，因此选择与containerd集成的用户不仅将获得Kubernetes的所有新功能，性能和稳定性的提高，还可以选择使用Docker Engine来满足其他需求。
容器中的
命名空间机制可确保
Kubelet和Docker Engine无法访问它们未创建的容器和映像。 这意味着它们不会互相干扰，以及：
- 输入docker
docker ps用户将不会看到在Kubernetes中创建的容器。 为此使用crictl ps 。 相反，用户将不会在Kubernetes或crictl ps命令上看到在Docker CLI中创建的容器。 crictl create和crictl run仅用于故障排除。 不建议在生产节点上使用crictl手动运行炉crictl或容器。 - 输入docker
docker images用户将看不到来自Kubernetes的图像。 为此，请使用crictl images命令。 相反，Kubernetes将看不到docker pull，docker docker load和docker build命令创建的图像。 为此，如果要加载映像，请使用crictl pull命令以及ctr cri load 。
总结
- 容器1.1具有本机CRI支持。 Kubernetes可以直接使用它。
- 容器化的1.1准备生产。
- 容器1.1在容器启动时间和系统资源利用率方面具有良好的性能。
- crictl是一个控制台（CLI）实用程序，用于与容器1.1和其他符合CRI的容器的运行时环境进行通信，以识别节点上的问题。
- Docker CE的下一个稳定版本将包含Containerd 1.1。 在非Kubernetes的情况下，用户可以选择继续使用Docker，并配置Kubernetes使用Docker的基础容器。
我们要感谢来自Google，IBM，Docker，ZTE，ZJU的每个人以及为这一切做出了贡献并使之成为可能的个人开发人员！
有关容器1.1的更改的详细列表，请参见
发行说明 。
如何尝试
设置Kubernetes集群以使用容器化作为默认运行时的说明：
- 对于GCE上的集群，使用
kube-up.sh引发kube-up.sh ; - 在这里使用Ansible和kubeadm安装许多节点的集群;
- 在Google Cloud中从头开始创建集群-请参阅“ Kubernetes的艰辛路 ”；
- 从tarball档案库进行手动安装;
- 使用LinuxKit在本地虚拟机上进行安装- 这里 。
如何贡献
Containered CRI插件-GitHub上的一个开源项目，它是containerd的一部分：
https :
//github.com/containerd/cri 。 欢迎所有提议的更改，包括意见，建议，更正的形式。 该开发人员入门
指南是进行更改的良好起点。
译者的PS
另请参阅我们的博客：