K8S工作節點的演變：由Docker到CRI-O

K8S工作節點的演變：由Docker到CRI-O

隨著K8S的崛起，OCI的推出，容器和雲架構逐漸發展完善，一個純開源的、社區的，完美的和高效的容器生態體系正在形成和在各個企業生產環境中使用。而生態體系中最重要的一環就是其Node，工作節點的演變，本文我們我說說K8S工作節點的演變和OCI標準下生態體系。

工作節點的演化

我們回顧一下K8S體系架構的發展，其中工作節點的運行時容器的已經發了重大的變化和調優，有以Docker為主導的容器發展成了有OCI標準的的CRI-O工具鏈形式。

docker主導

該階段主要以簡單的kubelet體系結構作為工作節點代理開始，作為工作節點代理通過api-server從主節點接收來管理的命令。Kubelet使用Docker運行時來啟動Docker容器（包括從註冊表中拉鏡像）。

CRI（容器運行時接口）

容器運行時接口（CRI）規範是在K8s 1.5中引入的。CRI規範還包括協議緩衝區，gRPC API和庫。通過在kubelet中運行的gRPC客戶端和在CRI Shim中運行的gRPC伺服器。該規範給K8S架構體系帶來抽象層，並充當了適配器。這允許以更簡單的方式運行各種容器運行時。

這些功能分為2個層次：

高級別功能：鏡像管理，傳輸，鏡像解壓縮和API，發送命令來運行容器，網絡，存儲（例如：rkt，docker，LXC等）。

低級別功能： 運行容器。

這些功能可以拆分獨立出各個部分來，各個部分可以選用各種開源組件，並搭配成更合理更高效的組合。

OCI、CRI-O 和工具鏈生態

OCI（開放容器倡議）提出了明確的容器運行時和鏡像規範，該規範有助於實現多平臺支持（Linux，Windows，VM等）。Runc是OCI的默認實現，它是容器運行時的底層。代的容器運行時基於該分層體系結構，其中Kubelet通過CRI-gRPC與容器運行時進行通信，而容器運行時通過OCI運行容器。CRI有多種實現，例如Docker shim，CRI-O，containerD。

podman

無守護程序容器引擎，用於開發管理和運行OCI容器，在一定程度上可以取代Docker CLI語言，可以docker命令大多數命令（RUN，PUSH，PULL等），甚至可以將其直接作為docker別名使用即可。

buildah

buuildah幫助構建OCI鏡像的工具。用戶不必關注象鏡像的組成，也不用編寫複雜的Dockerfile。相反，可以一次只構建一層鏡像，對其進行測試，然後回滾（如果需要），知道滿意，然後提交它到註冊表。

skopeo

完整的容器管理CLI工具。skopeo功能之一就是可以直接在遠程註冊表中無需下載或者解壓，就可以檢查鏡像。skopeo目前已經發展成為用於遠程註冊表的功能完善的鏡像管理工具，包括對鏡像進行籤名，在註冊表之間複製並保持遠程註冊表同步。這大大加快了容器構建，管理和部署管道速度。

CRI-O

CRI-O提供了可在OCI標準下一致的運行時和kubelet集成方式，提供一個kubelet容器運行時的接口：

支持更多鏡像的格式包括docker鏡像格式；

支持更多的方式來下載和驗證鏡像包；

容器鏡像管理（管理image的層，文件系統）；

容器進程的生命周期管理；

CRI所需求的監控和日誌；

CRI需求的資源隔離；

OpenShift

OpenShift包括整個生態鏈工具的。紅帽去年發布的Red Hat OpenShift 4.x系統，其容器運行時默認為CRI-O。可以使用CoreOS構建不可變的基礎架構，並在該基礎架構上運行OpenShift4.x。CRI-O以CoreOS為基礎是好處顯而易見的，最更重要的一點是CRI-O由k8s社區控制，完全開源，非常精簡，直接實現k8s容器運行時接口。