我们都知道Kubernetes不会直接和容器打交道，Kubernetes的使用者能接触到的概念只有pod，而pod里包含了多个容器。当我们在Kubernetes里用kubectl执行各种命令时，Kubernetes工作节点如何悄悄地为我们生成底层的容器呢？
这一切是通过Kubernetes工作节点里所谓“容器运行时”的软件在起作用。大家最熟悉的容器运行时软件当然是Docker，然而Docker只是Kubernetes支持的容器运行时技术的一种。
为了让Kubernetes不和某种特定的容器运行时技术绑死，而是能无需重新编译源代码就能够支持多种容器运行时技术的替换，和我们面向对象设计中引入接口作为抽象层一样，在Kubernetes和容器运行时之间我们引入了一个抽象层，即容器运行时接口。
在CRI还没有问世的Kubernetes早期版本里，比如1.3版本里，添加了对另一个容器运行时技术rkt的支持，即rktnetes项目。
这个项目虽然让Kubernetes增加了除Docker之外的另一种容器运行时的支持，然而这种增强的实现方式是通过直接修改kubelet实现源代码进行的，需要贡献者非常熟悉kubelet内部原理，开发门槛较高。
为了实现一个真正支持可插拔替换的容器运行时的机制，Kubernetes引入了CRI的概念。
有了CRI后，kubelet不再直接和容器运行时交互，而是通过CRI这个中间层。
如上图所示，kubelet和CRI通过Unix 套接字或者gRPC框架进行通信。
上图中的CRI protobuf意思是protocol buffers API，包含了两个gRPC服务：ImageService和RuntimeService。
首先什么是gRPC呢？
这个链接里有介绍：
https://hub.docker.com/r/grpc/go
gRPC是一个高性能开源的通用RPC(Remote Procedure Call)框架，优先考虑和充分利用了移动和HTTP/2.0, 在很多编程语言里都有对应的实现。
ImageService提供了从镜像仓库拉取、查看、和移除镜像的RPC。如此一来，kubelet根本不用操心底层容器使用的是Docker还是rkt还是其他容器，kubelet只需要调用gRPC客户端，gRPC客户端再进行RPC调用，从ImageService那里执行容器镜像操作，并将应答返回给kubelet。通过引入这个中间层，容器运行时的具体实现对kbelet就是完全透明的了。
ImageService解决了容器镜像管理这一静态需求，而另一个RuntimeSerivce，故名思议，包含了Pods和容器生命周期管理(增删改查)的RPC，以及跟容器交互的调用(exec/attach/port-forward)等等。
这个问题的解决思路再次体现了《代码大全2》里提到的那句经典名言：
any problem in computer science can be sloved by another layer of indirecition
计算机科学领域的任何问题都可以通过增加一个中间层来解决
相信这种引用抽象层来隔离变化，隔离实现细节的思路对大家平时工作做设计也一定大有帮助。
要获取更多Jerry的原创文章，请关注公众号"汪子熙":
