Kubernetes containerd集成的alpha版本于2017年11月推出，现在已经实现了一个非常重要的里程碑，与containerd的集成普遍可用。让我们来看看这对我们意味着什么！

根据Kubernetes博客介绍，containerd 1.1现在可以成为Kubernetes集群生产环境的容器运行时！

Containerd 1.1适用于Kubernetes 1.10及以上版本，并支持所有Kubernetes功能。在Kubernetes测试基础架构中Google云平台上containerd集成的测试覆盖率现在相当于Docker的集成。

这对我们意味着什么？

我们正在谈论双重演变。对于以前的版本（1.0），需要一个名为cri-containerd的后台进程来在Kubelet和containerd之间进行操作。简而言之，这个后台进程“处理来自Kubelet的Container Runtime Interface（CRI）服务请求，并使用containerd相应地管理容器和容器镜像。然而，cri-containerd和containerd 1.0仍然是两种不同的后台进程，它们通过grpc进行交互。”

引入containerd 1.1，所有问题都消失了; cri-containerd后台进程现在被重构为一个容器化的CRI插件。由于该插件内置于1.1版本，并且默认启用，因此你不再需要cri-containerd后台进程。

你应该知道，自Docker Community Edition（Docker CE）的下一个版本将使用containerd 1.1以来，默认情况下，CRI插件将被内置并启用。因此，你可以继续将Docker Engine用于Docker用户的其他用途，也可以“将Kubernetes配置为使用Docker Engine附带的容器并在同一节点上同时使用Docker Engine。”

由于Kubilelet和Docker Engine都使用containerd，所以如果选containerd集成，你将获得新的Kubernetes功能，性能和稳定性改进，以及为其他用例保留Docker Engine的选项。

关于containerd1.1

• Containerd 1.1原生支持CRI。它可以直接由Kubernetes使用。
• containerd 1.1已准备就绪。
• Containerd 1.1在Pod启动延迟和系统资源利用率方面表现出色。
• crictl是CLI工具，用于与containerd 1.1以及其他符合CRI的容器运行时进行节点故障排除。
• Docker CE的下一个稳定版本将包含containerd 1.1。用户可以选择继续将Docker用于不特定于Kubernetes的用例，并将Kubernetes配置为使用Docker附带的相同底层containerd。