k8s之CRI(容器运行时接口)

归根结底，Kubernetes Node(kubelet)的主要功能就是启动和停止 容器的组件，我们称之为容器运行时(Container Runtime)，其中最知 名的就是Docker了。为了更具扩展性，Kubernetes从1.5版本开始就加入 了容器运行时插件API，即Container Runtime Interface，简称CRI。

每个容器运行时都有特点，因此不少用户希望Kubernetes能够支持 更多的容器运行时。Kubernetes从1.5版本开始引入了CRI接口规范，通 过插件接口模式，Kubernetes无须重新编译就可以使用更多的容器运行 时。CRI包含Protocol Buffers、gRPC API、运行库支持及开发中的标准 规范和工具。Docker的CRI实现在Kubernetes 1.6中被更新为Beta版本， 并在kubelet启动时默认启动。

可替代的容器运行时支持是Kubernetes中的新概念。在Kubernetes 1.3发布时，rktnetes项目同时发布，让rkt容器引擎成为除Docker外的又 一选择。然而，不管是Docker还是rkt，都用到了kubelet的内部接口，同 kubelet源码纠缠不清。这种程度的集成需要对kubelet的内部机制有非常 深入的了解，还会给社区带来管理压力，这就给新生代容器运行时造成 了难于跨越的集成壁垒。CRI接口规范试图用定义清晰的抽象层清除这 一壁垒，让开发者能够专注于容器运行时本身。在通向插件式容器支持 及建设健康生态环境的路上，这是一小步，也是很重要的一步。

kubelet使用gRPC框架通过UNIX Socket与容器运行时(或CRI代 理)进行通信。在这个过程中kubelet是客户端，CRI代理(shim)是服 务端，如图2.3所示。

 

 

图2.3 CRI的主要组件
Protocol Buffers API包含两个gRPC服务:ImageService和

RuntimeService。

ImageService提供了从仓库拉取镜像、查看和移除镜像的功能。

RuntimeService负责Pod和容器的生命周期管理，以及与容器的交互 (exec/attach/port-forward)。rkt和Docker这样的容器运行时可以使用一 个Socket同时提供两个服务，在kubelet中可以用--container-runtime- endpoint和--image-service-endpoint参数设置这个Socket。

文章来源于k8s指南