Kubernetes-三大開放介面-初見

目錄

容器運行時介面CRI

歷史

OCI出現是為了它的核心目標圍繞容器的格式和運行時制定一個開放的工業化標準,並推動這個標準,保持容器的靈活性和開放性,容器能運行在任何的硬體和系統上。容器不應該綁定到特定的客戶機或編排堆棧,不應該與任何特定的供應商緊密關聯,並且可以跨多種作業系統
官網上對 OCI 的介紹如下：

Established in June 2015 by Docker and other leaders in the container industry, the OCI currently contains two specifications: the Runtime Specification (runtime-spec) and the Image Specification (image-spec). The Runtime Specification outlines how to run a 「filesystem bundle」 that is unpacked on disk. At a high-level an OCI implementation would download an OCI Image then unpack that image into an OCI Runtime filesystem bundle. At this point the OCI Runtime Bundle would be run by an OCI Runtime.

OCI由docker以及其他容器行業領導者創建於2015年，目前主要有兩個標準：容器運行時標準(runtime-spec)和容器鏡像標準(image-spec)。

這兩個標準通過OCI runtime filesytem bundle的標準格式連接在一起，OCI鏡像可以通過工具轉換成bundle，然後 OCI 容器引擎能夠識別這個bundle來運行容器

文檔主要做了兩個事情:

  • 創建鏡像的規則
  • 運行鏡像的規則

了解了OCI，以及docker在兼容OCI標準架構的調整後, 迎來我們的重點 CRI，CRI是kubernetes推出的一個標準，推出標準可見其在容器編排領域的地位。

簡介

容器運行時介面（Container Runtime Interface），簡稱 CRI。CRI 中定義了 容器 和 鏡像 的服務的介面，因為容器運行時與鏡像的生命周期是彼此隔離的，因此需要定義兩個服務。該介面使用 Protocol Buffer，基於 gRPC，在 Kubernetes v1.10 + 版本中是在 pkg/kubelet/apis/cri/runtime/v1alpha2 的 api.proto 中定義的。

容器運行時（Container Runtime）：顧名思義就是容器從拉取鏡像到啟動運行再到中止的整個生命周期。 其中最知名的就是Docker了。

每個容器運行時都有特點，因此不少用戶希望Kubernetes能夠支援更多的容器運行時。為了更具擴展性，kubernetes引入了容器運行時插件API，即 Container Runtime Interface，簡稱CRI。

  • Protocol Buffers API（一種更高效的類似json的數據格式）包含兩個gRPC服務:
    • ImageService和RuntimeService。
      • ImageService提供了從倉庫拉取鏡像、查看和移除鏡像的功能。
      • RuntimeService負責Pod和容器的生命周期管理，以及與容器的交互 (exec/attach/port-forward)。

架構

Container Runtime 實現了 CRI gRPC Server，包括 RuntimeService 和 ImageService。該 gRPC Server 需要監聽本地的 Unix socket，而 kubelet 則作為 gRPC Client 運行。

啟用 CRI

除非集成了 rktnetes，否則 CRI 都是被默認啟用了，從 Kubernetes 1.7 版本開始，舊的預集成的 docker CRI 已經被移除。

要想啟用 CRI 只需要在 kubelet 的啟動參數重傳入此參數：--container-runtime-endpoint 遠程運行時服務的端點。當前 Linux 上支援 unix socket，windows 上支援 tcp。

Kubelet拉起一個容器的過程：

  1. Kubelet通過CRI介面(gRPC)調用docker-shim，請求創建一個容器這一步中，kubelet可以視作一個簡單的CRI Client，而docker-shim就是接收請求的Server，注意的是docker-shim是內嵌在Kubelet中的。

  2. docker-shim收到請求後，轉化成Docker Daemon能聽懂的請求，發到Docker Daemon上請求創建一個容器

  3. Docker Daemon請求containerd創建一個容器

  4. containerd收到請求後創建一個containerd-shim進程,通過containerd-shim操作容器，容器進程需要一個父進程來做諸如收集狀態， 維持stdin等fd打開等工作

  5. containerd-shim在調用runC來啟動容器

  6. runC 啟動完容器後本身會直接退出，containerd-shim則會成為容器進程的父進程，負責收集容器進程的狀態，上報給containerd。

通過上面kubelet創建容器的流程, 我們可以看到kubelet通過CRI的標準來與外部容器運行時進行交互。

kubernetes 早期版本1.5之前內置了docker和rkt，也就是支援兩種運行時, 這個時候如果用戶想自定義運行時就比較痛苦了,需要修改kubelet源碼。

同時不同的容器運行時各有所長，隨著k8s在容器編排領域裡面老大的地位，許多用戶希望kubernetes支援更多的容器運行時，滿足不同用戶，不同環境的使用。

於是從kubernetes1.5開始增加了CRI介面, 有了CRI介面無需修改kubelet源碼就可以支援更多的容器運行時，

與此同時內置的docker和rtk逐漸從kubernetes源碼中移除，到kubernetes1.11版本Kubelet內置的rkt程式碼刪除，CNI的實現遷移到dockers-shim之內,除了docker之外，其他的容器運行時都通過CRI接入。

外部的容器運行時一般稱為CRI shim，它除了實現CRI介面外，也要負責為容器配置網路，即CNI，有了CNI可以支援社區內的眾多網路插件。

CRI 介面

CRI主要定義兩個介面， ImageService和RuntimeService，如下圖：

ImageService：負責鏡像的生命管理周期

  • 查詢鏡像列表
  • 拉取鏡像到本地
  • 查詢鏡像狀態
  • 刪除本地鏡像
  • 查詢鏡像佔用空間

RuntimeService：負責管理Pod和容器的生命周期

  • PodSandbox 的管理介面
    PodSandbox是對kubernete Pod的抽象，用來給容器提供一個隔離的環境(比如掛載到相同的cgroup下面)並提供網路等共享的命名空間。PodSandbox通常對應到一個Pause容器或者一台虛擬機。
  • Container 的管理介面
    在指定的 PodSandbox 中創建、啟動、停止和刪除容器。
  • Streaming API介面
    包括Exec、Attach和PortForward 等三個和容器進行數據交互的介面，這三個介面返回的是運行時Streaming Server的URL，而不是直接跟容器交互。
  • 狀態介面
    包括查詢API版本和查詢運行時狀態。

容器生態可以下面的三層抽象:

Orchestration API -> Container API -> Kernel API

  • Orchestration API: kubernetes API標準就是這層的標準,無可非議
  • Container API: 標準就是CRI
  • Kernel API: 標準就是OCI

當前支援的 CRI 後端

我們最初在使用 Kubernetes 時通常會默認使用 Docker 作為容器運行時，其實從 Kubernetes 1.5 開始已經支援 CRI，通過 CRI 介面可以指定使用其它容器運行時作為 Pod 的後端，目前支援 CRI 的後端有：

  • cri-o：cri-o 是 Kubernetes 的 CRI 標準的實現，並且允許 Kubernetes 間接使用 OCI 兼容的容器運行時，可以把 cri-o 看成 Kubernetes 使用 OCI 兼容的容器運行時的中間層。
  • cri-containerd：基於 Containerd 的 Kubernetes CRI 實現
  • rkt：由 CoreOS 主推的用來跟 docker 抗衡的容器運行時
  • frakti：基於 hypervisor 的 CRI
  • docker：Kuberentes 最初就開始支援的容器運行時，目前還沒完全從 kubelet 中解耦，Docker 公司同時推廣了 OCI 標準

CRI 是由 SIG-Node 來維護的。

容器網路介面CNI

簡介

容器網路介面（Container Network Interface），簡稱 CNI，是 CNCF 旗下的一個項目，由一組用於配置 Linux 容器的網路介面的規範和庫組成，同時還包含了一些插件。CNI 僅關心容器創建時的網路分配，和當容器被刪除時釋放網路資源。有關詳情請查看 GitHub。

Kubernetes 源碼的 vendor/github.com/containernetworking/cni/libcni 目錄中已經包含了 CNI 的程式碼，也就是說 Kubernetes 中已經內置了 CNI。

為什麼出現？

不管是 Docker 還是 Kubernetes，在網路方面目前都沒有一個完美的、終極的、普適性的解決方案，不同的用戶和企業因為各種原因會使用不同的網路方案。

目前存在網路方案 flannel、calico、openvswitch、weave、ipvlan等，而且以後一定會有其他的網路方案，這些方案介面和使用方法都不相同，而不同的容器平台都需要網路功能，它們之間的適配如果沒有統一的標準，會有很大的工作量和重複勞動。

CNI 就是這樣一個標準，它旨在為容器平台提供網路的標準化。不同的容器平台（比如目前的 kubernetes、mesos 和 rkt）能夠通過相同的介面調用不同的網路組件。

CNI(Conteinre Network Interface) 是 Google 和 CoreOS 主導制定的容器網路標準，它本身並不是實現或者程式碼，可以理解成一個協議。這個標準是在 rkt 網路提議 的基礎上發展起來的，綜合考慮了靈活性、擴展性、ip 分配、多網卡等因素。

這個協議連接了兩個組件：容器管理系統和網路插件。它們之間通過 JSON 格式的文件進行通訊，實現容器的網路功能。具體的事情都是插件來實現的，包括：創建容器網路空間（network namespace）、把網路介面（interface）放到對應的網路空間、給網路介面分配 IP 等等。

關於網路，Docker 也提出了 CNM 標準，它要解決的問題和 CNI 是重合的，也就是說目前兩者是競爭關係。

目前 CNM 只能使用在 Docker 中，而 CNI 可以使用在任何容器運行時。CNM 主要用來實現 docker 自身的網路問題，也就是 docker network 子命令提供的功能。

介面定義

CNI 的介面中包括以下幾個方法：

type CNI interface {
    AddNetworkList (net *NetworkConfigList, rt *RuntimeConf) (types.Result, error)
    DelNetworkList (net *NetworkConfigList, rt *RuntimeConf) error
    AddNetwork (net *NetworkConfig, rt *RuntimeConf) (types.Result, error)
    DelNetwork (net *NetworkConfig, rt *RuntimeConf) error
}

該介面只有四個方法，添加網路、刪除網路、添加網路列表、刪除網路列表。

官方網路插件

所有的標準和協議都要有具體的實現，才能夠被大家使用。CNI 也不例外，目前官方在 github 上維護了同名的 CNI 程式碼庫，裡面已經有很多可以直接拿來使用的 CNI 插件。

官方提供的插件目前分成三類：main、meta 和 ipam。main 是主要的實現了某種特定網路功能的插件；meta 本身並不會提供具體的網路功能，它會調用其他插件，或者單純是為了測試；ipam 是分配 IP 地址的插件。

ipam 並不提供某種網路功能，只是為了靈活性把它單獨抽象出來，這樣不同的網路插件可以根據需求選擇 ipam，或者實現自己的 ipam。

這些插件的功能說明如下：

  • main
    • loopback：這個插件很簡單，負責生成 lo 網卡，並配置上 127.0.0.1/8 地址
    • bridge：和 docker 默認的網路模型很像，把所有的容器連接到虛擬交換機上
    • macvlan：使用 macvlan 技術，從某個物理網卡虛擬出多個虛擬網卡，它們有獨立的 ip 和 mac 地址
    • ipvlan：和 macvlan 類似，區別是虛擬網卡有著相同的 mac 地址
    • ptp：通過 veth pair 在容器和主機之間建立通道
  • meta
    • flannel：結合 bridge 插件使用，根據 flannel 分配的網段資訊，調用 bridge 插件，保證多主機情況下容器
  • ipam
    • host-local：基於本地文件的 ip 分配和管理，把分配的 IP 地址保存在文件中
    • dhcp：從已經運行的 DHCP 伺服器中獲取 ip 地址

介面參數

網路插件是獨立的可執行文件，被上層的容器管理平台調用。網路插件只有兩件事情要做：把容器加入到網路以及把容器從網路中刪除。調用插件的數據通過兩種方式傳遞：環境變數和標準輸入。一般插件需要三種類型的數據：容器相關的資訊，比如 ns 的文件、容器 id 等；網路配置的資訊，包括網段、網關、DNS 以及插件額外的資訊等；還有就是 CNI 本身的資訊，比如 CNI 插件的位置、添加網路還是刪除網路。

我們來看一下為容器添加網路是怎麼工作的，刪除網路和它過程一樣。

把容器加入到網路

調用插件的時候，這些參數會通過環境變數進行傳遞：

  • CNI_COMMAND：要執行的操作，可以是 ADD（把容器加入到某個網路）、DEL（把容器從某個網路中刪除）
  • CNI_CONTAINERID：容器的 ID，比如 ipam 會把容器 ID 和分配的 IP 地址保存下來。可選的參數，但是推薦傳遞過去。需要保證在管理平台上是唯一的，如果容器被刪除後可以循環使用
  • CNI_NETNS：容器的 network namespace 文件，訪問這個文件可以在容器的網路 namespace 中操作
  • CNI_IFNAME：要配置的 interface 名字，比如 eth0
  • CNI_ARGS：額外的參數，是由分號;分割的鍵值對，比如 「FOO=BAR;hello=world」
  • CNI_PATH：CNI 二進位查找的路徑列表，多個路徑用分隔符 : 分隔

網路資訊主要通過標準輸入，作為 JSON 字元串傳遞給插件，必須的參數包括：

  • cniVersion：CNI 標準的版本號。因為 CNI 在演化過程中，不同的版本有不同的要求
  • name：網路的名字，在集群中應該保持唯一
  • type：網路插件的類型，也就是 CNI 可執行文件的名稱
  • args：額外的資訊，類型為字典
  • ipMasq：是否在主機上為該網路配置 IP masquerade
  • ipam：IP 分配相關的資訊，類型為字典
  • dns：DNS 相關的資訊，類型為字典

插件接到這些數據，從輸入和環境變數解析到需要的資訊，根據這些資訊執行程式邏輯，然後把結果返回給調用者，返回的結果中一般包括這些參數：

  • IPs assigned to the interface：網路介面被分配的 ip，可以是 IPv4、IPv6 或者都有
  • DNS 資訊：包含 nameservers、domain、search domains 和其他選項的字典

CNI 協議的內容還在不斷更新，請到官方文檔獲取當前的資訊。

CNI 的特性

CNI 作為一個協議/標準，它有很強的擴展性和靈活性。如果用戶對某個插件有額外的需求，可以通過輸入中的 args 和環境變數 CNI_ARGS 傳輸，然後在插件中實現自定義的功能，這大大增加了它的擴展性；CNI 插件把 main 和 ipam 分開，用戶可以自由組合它們，而且一個 CNI 插件也可以直接調用另外一個 CNI 插件，使用起來非常靈活。

如果要實現一個繼承性的 CNI 插件也不複雜，可以編寫自己的 CNI 插件，根據傳入的配置調用 main 中已經有的插件，就能讓用戶自由選擇容器的網路。

在 kubernetes 中的使用

CNI 目前已經在 kubernetes 中開始使用，也是目前官方推薦的網路方案，具體的配置方法可以參考kubernetes 官方文檔。

kubernetes 使用了 CNI 網路插件之後，工作過程是這樣的：

  • kubernetes 先創建 pause 容器生成對應的 network namespace
  • 調用網路 driver（因為配置的是 CNI，所以會調用 CNI 相關程式碼）
  • CNI driver 根據配置調用具體的 cni 插件
  • cni 插件給 pause 容器配置正確的網路
  • pod 中其他的容器都是用 pause 的網路

容器存儲介面CSI

背景

Kubernetes原生支援一些存儲類型的 PV，如 iSCSI、NFS、CephFS 等等，這些 in-tree 類型的存儲程式碼放在 Kubernetes 程式碼倉庫中。這裡帶來的問題是 Kubernetes 程式碼與三方存儲廠商的程式碼強耦合：

  • 更改 in-tree 類型的存儲程式碼，用戶必須更新 Kubernetes組件，成本較高
  • in-tree 存儲程式碼中的 bug 會引發 Kubernetes組件不穩定
  • Kubernetes社區需要負責維護及測試 in-tree 類型的存儲功能
  • in-tree 存儲插件享有與 Kubernetes核心組件同等的特權，存在安全隱患
  • 三方存儲開發者必須遵循 KKubernetes8s 社區的規則開發 in-tree 類型存儲程式碼

CSI 容器存儲介面標準的出現解決了上述問題，將三方存儲程式碼與 Kubernetes程式碼解耦，使得三方存儲廠商研發人員只需實現 CSI 介面（無需關注容器平台是 Kubernetes還是 Swarm 等）。

簡介

容器存儲介面（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。

參考

//www.jianshu.com/p/c7748893ab00

//jimmysong.io/kubernetes-handbook/concepts/cni.html

//www.kubernetes.org.cn/9127.html

Tags:

VirMach 便宜 VPS

QNews

QNews