我們都知道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的原創文章，請關注公眾號"汪子熙":

總結

以上是生活随笔為你收集整理的什么是Kubernetes的CRI - 容器运行时接口的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。