Kubernetes container runtime interface

题记:最近一段时间在做Kubernetes容器引擎接口(Container Runtime Interface, CRI)的重构,并支持以插件的方式引入外部容器引擎。CRI还在紧张有序的开发中,预计在v1.5发布第一个alpha版。

什么是CRI

CRI是Kubelet(负责管理容器生命周期的服务)与容器引擎之间的接口。为了适应多种不同的容器引擎,Kubelet在加入rkt的时候就已经在docker API的基础上抽象了一个Runtime接口,只是由于一些特定的缺陷,在这个接口上不太容易引入其他新的容器引擎:

既然Runtime接口有很多问题,并且有很多容器引擎想要集成到Kubernetes中,所以有必要重新定义CRI,并且提供一种插件机制,允许容器引擎以外部独立进程的方式接入。所以,Brendan Burns在Hyper集成的时候就提供了一种以客户端/服务器方式接入外部容器引擎的思路。在大量的社区讨论后,Node team重新抽象了容器引擎接口(也就是CRI),并决定以gRPC的方式接入外部容器引擎。

CRI是如何工作的

CRI比Runtime接口提供了更细粒度的抽象,解耦了镜像管理和容器管理,并为Pod和Container提供了独立的操作接口。CRI以gRPC的方式接入,Kubelet是gPRC API的客户端,而容器引擎则是gRPC API的服务端。gRPC已经自动实现了它们之间交互的细节,容器引擎只需要实现每个具体的API。

一个典型的启动Pod的流程为

createpod

而停止Pod的流程为

killpod

CRI带了什么

CRI解决了上述提到的Runtime接口的问题,使得新的容器引擎可以更方便的集成到Kubernetes中来,这必将给Kubernetes社区带来新一轮的变革,并促进Kubernetes走入更多的应用场景中。比如,Redhat借助OCI容器引擎runc摆脱对docker依赖,Hyper以虚拟化的方式解决多租户场景下的容器隔离问题,甚至Mirantis直接用Kubernetes来管理原生的虚拟机。

CRI也解耦了容器和镜像的管理,可以方便的扩展其他镜像格式,比如ACI等。

CRI还在着力解决一些很有挑战的问题,比如

CRI的未来

虽然CRI还在持续开发中(目前还没有任何release),但已经有很多厂商已经开始了引入新容器引擎的进程:

CRI预计在Kubernetes v1.5发布第一个alpha版。届时,上面各个容器引擎的实现也将会发布第一个release。

Comments

comments powered by Disqus