[Kubernetes] CRI 的設計與工做原理

我們來看看,有了 CRI 以後, Kubernetes 的架構圖:

咱們能夠看到, CRI 機制可以發揮做用的核心,在於每個容器項目如今均可以本身實現一個 CRI shim ,自行對 CRI 請求進行處理.這樣, Kubernetes 就有了一個統一的容器抽象層,使得下層容器在運行的時候,能夠自由地對接,從而進入 Kubernetes 當中去.
做爲一個 CRI shim , container 對 CRI 的具體實現,又是怎樣的呢?這個時候,咱們就須要去看看 CRI 這個接口的定義裏面都有什麼了.

咱們可以看到, CRI 待實現接口,主要有兩類:

• RuntimeService .它提供的接口,主要就是和容器有關的操做.好比,建立和啓動容器,刪除容器,執行 exec 命令等.
• ImageService .它提供的接口,主要是和容器鏡像相關的操做,好比 拉取鏡像,刪除鏡像等等.

我們主要來看 RuntimeService 這一部分.在這裏, CRI 設計的一個重要原則,就是確保這個接口自己,只關注容器,不關注 Pod .之因此這樣的緣由有兩個:第一, Pod 是 Kubernetes 的編排概念,而不是容器運行時的概念,因此就不能假設全部的下層容器項目,都可以暴露出能夠直接映射爲 Pod 的 API .第二,若是 CRI 裏面引入了 Pod 的概念,那麼只要 Pod API 對象的字段發生變化,那麼 CRI 就頗有可能須要變動.基於以上緣由, CRI 設計中,並無一個直接建立 Pod 或者啓動 Pod 的接口.
CRI shim 還有一個重要的工做,就是如何實現 exec , logs 等接口.這些接口不一樣在於, gRPC 接口調用期間, kubelet 須要和容器項目維護一個長鏈接來傳輸數據.這種 API ,就稱之爲 Streaming API .
CRI shim 中對 Streaming API 的實現,依賴於一套獨立的 Streaming Server 機制,以下:

當對一個容器執行 kubectl exec 命令時,這個請求首先會交給 API Server , 而後 API Server 就會調用 kubelet 的 Exec API .此時, kubelet 會調用 CRI 的 Exec 接口,而負責響應這個接口的,就是 CRI shim .可是在這一步, CRI shim 並不會直接去調用後端的容器項目(好比 Docker )來進行處理,而只會返回一個 URL 給 kubelet .這個 URL ,就是該 CRI shim 對應的 Streaming Server 的地址和端口.
kubelet 在拿到這個 URL 以後,就會把它以 Redirect 的方式返回給 API Server .因此這個時候, API Server 就會經過重定向來向 Streaming Server 發起真正的 /exec 請求,和它創建長鏈接.
Stream Server 這一部分具體怎麼實現,徹底能夠由 CRI shim 的維護者自行決定.

因此, CRI 這個接口的設計,實際上仍是比較寬鬆的.這就意味着,做爲容器項目的維護者,在實現 CRI 的具體接口時,每每擁有着很高的自由度,這個自由度不只包括了容器的生命週期管理,也包括瞭如何將 Pod 映射成本身的實現,還包括瞭如何調用 CNI 插件來爲 Pod 設置網絡的過程.
基於此,當你對容器這一層有特殊的需求時,優先建議考慮實現一個本身的 CRI shim .

以上就是關於 CRI 的設計與工做原理的一些內容了.
以上內容來自我學習<深刻剖析Kubernetes>專欄文章以後的一些看法,有偏頗之處,還望指出.
感謝您的閱讀~