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的开发使他们能够“在诸如性能等功能上展开竞争,同时确保能够兼容。“