日前SUSE釋出自家容器服務平臺第三版(SUSE CaaS Platform 3),新版提供了更多容器叢集最佳化的配置選項,可以讓開發者對SUSE自家容器專用作業系統MicroOS,提供更精細的調整。而在近日該公司也宣布,現在SUSE CaaS平臺已開始將CRI-O列入開發者可選用的容器Runtime。

SUSE表示,現在SUSE CaaS平臺登入的組態設定選單中,開發者就可以自行選擇,使用CRI-O或者Docke開源引擎作為容器Runtime。雖然當前系統仍然預設使用Docker,不過SUSE的未來布局,是計畫先透過此技術預覽功能,蒐集使用者回饋後,並且預計在下個新版本SUSE CaaS平臺第4版,正式支援CRI-O。

CRI-O這個Runtime格式,同時相容Kubernetes Runtime Interface、開放容器標準(Open Container Initiative,OCI),SUSE也認為,相比其他容器Runtime,CRI-O是個更輕量的替代方案,還可以加強容器環境的安全性、穩定性。身為CRI-O開發社群SUSE表示,最初Kubernetes快速改版革新、各家Container格式不一,讓此專案穩定性遭受挑戰,這也催生出Kubernetes專用的CRI-O,一舉減少程式碼數量,讓潛在攻擊面縮小,同時也更容易維護。除了設計理念不同,「Docker的目的是要支援多使用情境,反之,CRI-O則鎖定支援Kubernetes。」SUSE表示。

SUSE解釋,Kubelet透過gRPC遠端程序呼叫CRI-O,接著CRI-O便會開始建立Kubernetes CRI運作所需的元件、服務,像是建置系統服務,串接容器映像檔下載、上傳的工作,或者設定好容器網路,讓容器、Pod可以互相連線。相比功能豐富的Docker Daemon,「CRI-O的功能則輕薄了許多。」

開發者就可以自行選擇,使用CRI-O或者Docke開源引擎作為容器Runtime。目前SUSE CaaS平臺雖預設使用Docker,不過SUSE的未來布局,是計畫先透過此技術預覽功能,蒐集使用者回饋後,並且預計在下個新版本SUSE CaaS平臺第4版,正式支援CRI-O。圖片來源:SUSE

Kubelet透過gRPC遠端程序呼叫CRI-O,接著CRI-O便會開始建立Kubernetes CRI運作所需的元件、服務,像是建置系統服務,串接容器映像檔下載、上傳的工作,或者設定好容器網路,讓容器、Pod可以互相連線。圖片來源:SUSE


Advertisement

更多 iThome相關內容