Kubernetes社区宣布正式支持Containerd 1.1版，并推出了容器runtime接口(container runtime interface，CRI)。

最新的Containerd 1.1规范合并了1.0所需的额外步骤，以消除可能影响稳定性和效率的“跳跃”。特别是，Containerd 1.1集成了以前的外部cri- containerd守护进程，并允许将Kubernetes直接与Containerd 1.1一起使用。

容器runtime提供了一个API和用于抽象容器中初级技术细节的工具。守护进程是一个在后台运行并由特定事件激活的程序。

在1.0规范中，cri-containerd守护进程需要与Kubernetes一起工作。该守护进程是处理来自kubelet的服务请求的CRI，它是在每个节点上运行的主要“节点代理”，并使用Containerd来管理容器和容器映像。

谷歌软件工程师Lantao Liu和IBM开源开发者倡导者Mike Brown在一篇博客文章中解释说：“循环中的额外守护进程使得用户理解及部署变得更复杂，并引入了不必要的通信开销。”

双方表示，与目前的Docker CRI迭代相比，更新后的平台发布的pod启动延迟更低，CPU和内存使用率也更低。

Containerd 1.1支持3月份推出的最新Kubernetes 1.10版本，并支持所有容器编排器的功能，它还向后兼容1.0规范。

与最常用的Docker CRI相比，最初的1.0规范允许删除一个跃点。Docker Consumer Edition（CE）的下一个版本将包含Containerd 1.1，但用户可以继续使用Docker CRI查找不特定于Kubernetes的用例。但是1.1规范和Docker CRI将禁止由其他人创建的容器或图像接入。Containerd是构建Docker容器所需过程中的一部分。

Runtime Activity
最新的Containerd 1.1规范也被视为其他CRI选项的强化版替代方案。

CRI-O是其中之一，这是去年在开放容器倡议（OCI）符合runtime和Kubernetes kubelets的一个整合路径。它的设计仅供Kubernetes使用，并且是Kubernetes孵化器项目。

CRI-O被设计成其他runtime选项的“slimmer”替代品。Red Hat咨询工程师Daniel Walsh在CRI-O 1.0发布的博客文章中称，它不同于其他runtime选项，因为它不会尝试做太多事情。

他写道：“我们不想像所有容器runtime一样将所有锁定和容器状态都放入内存中，这样会使系统上的其他进程也不能使用映像和存储。” Walsh补充说，与其他容器runtime相比，更小的容量可以提供更好的Kubernetes性能。

Linux基金会开发人员计划副总裁Chris Aniszczyk指出，开源CRI的开发使他们能够“在诸如性能等功能上展开竞争，同时确保能够兼容。“