Kubernetes作為雲原生應用的基礎排程平臺，相當於雲原生的作業系統，為了便於系統的擴充套件，Kubernetes中開放的以下三個介面，可以分別對接不同的後端，來實現自己的業務邏輯。

• CRI（Container Runtime Interface）：容器執行時介面，提供計算資源
• CNI（Container Network Interface）：容器網路介面，提供網路資源
• CSI（Container Storage Interface）：容器儲存介面，提供儲存資源

1.CRI - Container Runtime Interface（容器執行時介面）

CRI中定義了 容器和 映象的服務的介面 ，因為容器執行時與映象的生命週期是彼此隔離的，因此需要定義兩個服務 —— RuntimeService和 ImageService 。

• RuntimeService：容器和Sandbox執行時管理。
• ImageService：提供了從映象倉庫拉取、檢視、和移除映象的RPC。

Container Runtime實現了CRI gRPC Server，CRI介面包含了上邊兩個gRPC服務， gRPC Server需要監聽本地的Unix socket，而kubelet則作為gRPC Client執行。

gRPC，其實就是RPC框架的一種，RPC 框架就是讓你可以像呼叫本地方法一樣呼叫遠端服務提供的方法，而不需要關心底層的通訊細節。簡單地說就讓遠端服務呼叫更加簡單、透明。 RPC包含了客戶端（Client）和服務端（Server） 。

gRPC前面帶了一個g，是一個 高效能、開源和通用的 RPC 框架，基於 ProtoBuf(Protocol Buffers) 序列化協議開發，且支援眾多開發語言。面向服務端和移動端，基於 HTTP/2 設計，帶來諸如雙向流、流控、頭部壓縮、單 TCP 連線上的多複用請求等特 。

 

啟用CRI

除非整合了rktnetes，否則CRI都是被預設啟用了，從Kubernetes1.7版本開始，舊的預整合的docker CRI已經被移除

要想啟用CRI只需要在kubelet的啟動引數重傳入引數： --container-runtime-endpoint遠端執行時服務的端點 。Linux上支援unix socket，windows上支援tcp。例如： unix:///var/run/dockershim.sock、  tcp://localhost:373，預設是 unix:///var/run/dockershim.sock，即預設使用本地的docker作為容器執行時 。

支援的CRI後端

從Kubernetes 1.5開始已經開始支援CRI ，通過CRI介面可以指定使用其它容器執行時作為Pod的後端，目前支援 CRI 的後端有：

• cri-o：同時相容OCI和CRI的容器執行時
• cri-containerd：基於 Containerd的Kubernetes CRI 實現
• rkt：由CoreOS主推的用來跟docker抗衡的容器執行時
• frakti：基於hypervisor的CRI
• docker：kuberentes最初就開始支援的容器執行時，目前還沒完全從kubelet中解耦，docker公司同時推廣了 OCI標準
• Clear Containers：由Intel推出的同時相容OCI和CRI的容器執行時
• Kata Containers：符合OCI規範同時相容CRI
• gVisor：由谷歌推出的容器執行時沙箱(Experimental)

2.CNI - Container Network Interface（容器網路介面）

CNI（Container Network Interface）是CNCF旗下的一個專案，由一組用於配置Linux容器的網路介面的規範和庫組成，同時還包含了一些外掛。 CNI僅關心容器建立時的網路分配，和當容器被刪除時釋放網路資源。

  kubernetes中已經內建了CNI。

CNI介面只有四個方法，新增網路、刪除網路、新增網路列表、刪除網路列表。

CNI外掛

CNI外掛必須實現一個可執行檔案，這個檔案可以被容器管理系統呼叫。

CNI外掛負責將網路介面插入容器網路名稱空間 ，並在主機上進行任何必要的改變（例如將veth的另一端連線到網橋）。然後將IP分配給介面，並通過呼叫適當的IPAM外掛來設定與“IP地址管理”部分一致的路由。

CNI外掛必須支援以下操作：

• 將容器新增到網路
• 從網路中刪除容器
• IP分配

作為容器網路管理的一部分，CNI外掛需要為介面分配（並維護）IP地址，並安裝與該介面相關的所有必要路由。這給了CNI外掛很大的靈活性，但也給它帶來了很大的負擔。 為了減輕負擔，使IP管理策略與CNI外掛型別解耦，我們定義了 IP地址管理外掛（IPAM外掛） 。CNI外掛的職責是在執行時恰當地呼叫IPAM外掛。 IPAM外掛必須確定介面IP/subnet，閘道器和路由，並將此資訊返回到“主”外掛來應用配置。

IPAM外掛---IP地址管理外掛

像CNI外掛一樣，呼叫IPAM外掛的可執行檔案。可執行檔案位於預定義的路徑列表中，通過 CNI_PATH指示給CNI外掛。 IPAM外掛必須接收所有傳入CNI外掛的相同環境變數。就像CNI外掛一樣，IPAM外掛通過stdin接收網路配置。

可用外掛

Main：介面建立

• bridge：建立網橋，並新增主機和容器到該網橋
• ipvlan：在容器中新增一個 ipvlan介面
• loopback：建立一個迴環介面
• macvlan：建立一個新的MAC地址，將所有的流量轉發到容器
• ptp：建立veth對
• vlan：分配一個vlan裝置

IPAM：IP地址分配

• dhcp：在主機上執行守護程式，代表容器發出DHCP請求
• host-local：維護分配IP的本地資料庫

Meta：其它外掛

• flannel：根據flannel的配置檔案建立介面

• tuning：調整現有介面的sysctl引數

• portmap：一個基於iptables的portmapping外掛。將埠從主機的地址空間對映到容器。

3.CSI - Container Storage Interface（容器儲存介面）

CSI 代表容器儲存介面，CSI 試圖建立一個行業標準介面的規範，藉助 CSI 容器編排系統（CO）可以將任意儲存系統暴露給自己的容器工作負載。

csi 卷型別是一種 out-tree（即跟其它儲存外掛在同一個程式碼路徑下，隨 Kubernetes 的程式碼同時編譯的） 的 CSI 卷外掛，用於 Pod 與在同一節點上執行的外部 CSI 卷驅動程式互動。部署 CSI 相容卷驅動後，使用者可以使用  csi 作為卷型別來掛載驅動提供的儲存。

CSI 持久化卷支援是在 Kubernetes v1.9 中引入的，作為一個 alpha 特性，必須由叢集管理員明確啟用。換句話說，叢集管理員需要在 apiserver、controller-manager 和 kubelet 元件的 “ --feature-gates =” 標誌中加上 “ CSIPersistentVolume = true”。

CSI 持久化卷具有以下欄位可供使用者指定：

• driver：一個字串值，指定要使用的卷驅動程式的名稱。必須少於 63 個字元，並以一個字元開頭。驅動程式名稱可以包含 “。”、“ - ”、“_” 或數字。
• volumeHandle：一個字串值，唯一標識從 CSI 卷外掛的  CreateVolume 呼叫返回的卷名。隨後在卷驅動程式的所有後續呼叫中使用卷控制程式碼來引用該卷。
• readOnly：一個可選的布林值，指示卷是否被髮布為只讀。預設是 false。