iSulad+Kuasar：管理面資源消耗銳減99%的新一代統(tǒng)一容器運(yùn)行時(shí)解決方案

隨著云計(jì)算和容器技術(shù)的不斷發(fā)展，容器引擎和容器運(yùn)行時(shí)已經(jīng)成為了云原生時(shí)代的基石，它們負(fù)責(zé)了容器生命周期的管理以及容器運(yùn)行過(guò)程中環(huán)境的創(chuàng)建和資源的配置。openEuler 社區(qū)基于容器引擎項(xiàng)目 iSulad[1]在解決容器運(yùn)行效率、安全性以及隔離性等問(wèn)題上進(jìn)行著不斷地嘗試與探索。

華為云在 2023 年 4 月 21 日阿姆斯特丹的 Kubecon+CloudNativeCon Europe 2023 云原生峰會(huì)上發(fā)布了多沙箱運(yùn)行時(shí)Kuasar[2]，將 Kubernetes CRI(https://github.com/kubernetes/cri-api) 標(biāo)準(zhǔn)中的 Pod 語(yǔ)義準(zhǔn)確地映射到了 Kuasar 的 Sandbox 語(yǔ)義。與此同時(shí)，iSulad 容器團(tuán)隊(duì)與華為云 Kuasar 緊密合作，率先支持了 Kuasar 的 Sandbox 語(yǔ)義，實(shí)現(xiàn)了從 Kubernetes 到 iSulad 容器引擎到 Kuasar 統(tǒng)一容器運(yùn)行時(shí)的全棧打通。通過(guò) iSulad 和 Kuasar 項(xiàng)目，統(tǒng)一了容器運(yùn)行時(shí)應(yīng)對(duì)不同容器隔離技術(shù)的 Kubernetes 生態(tài)場(chǎng)景，簡(jiǎn)化了單節(jié)點(diǎn)上多種容器（或沙箱）形態(tài)的統(tǒng)一部署。相比于 Containerd + Kata-Containers 的運(yùn)行時(shí)組合，iSulad + Kuasar「不僅可以支持多種容器隔離技術(shù)，而且使容器運(yùn)行時(shí)管理組件的內(nèi)存消耗減少了 99%，并行啟動(dòng)時(shí)間縮短了 40%以上！」

背景與現(xiàn)狀

從容器編排組件 Kubernetes 的視角來(lái)看，能夠處理 CRI(Container Runtime Interface)請(qǐng)求的服務(wù)端都是容器運(yùn)行時(shí)(Container Runtime)。事實(shí)上，容器運(yùn)行時(shí)還可以再細(xì)分為兩個(gè)層次，即容器引擎和底層容器運(yùn)行時(shí)。

容器引擎(Container Engine)主要負(fù)責(zé)容器運(yùn)行環(huán)境的創(chuàng)建、容器資源的配置和容器生命周期的管理，北向接收來(lái)自于 Kubernetes 或前端命令行的輸入，南向則調(diào)用底層容器運(yùn)行時(shí)(Low Level Container Runtime)來(lái)完成最終容器環(huán)境的生成和容器生命周期的操作。

在業(yè)界，容器引擎和容器運(yùn)行時(shí)的術(shù)語(yǔ)經(jīng)常被交替使用?！冈诒疚牡恼Z(yǔ)義中，容器運(yùn)行時(shí)特指底層容器運(yùn)行時(shí)」。除了 iSulad 以外，當(dāng)前的容器引擎還包括 Containerd，Docker 等，底層容器運(yùn)行時(shí)包括 runc，Kata-Containers 等。

這些容器引擎和容器運(yùn)行時(shí)由于一些歷史原因一直存在著不少遺留問(wèn)題。這些問(wèn)題主要是由于容器引擎和容器運(yùn)行時(shí)沒有妥善處理 CRI 中的 Pod 語(yǔ)義而引起的。下圖以 MicroVM 為例，簡(jiǎn)單介紹了一些容器引擎和容器運(yùn)行時(shí)中的主要問(wèn)題。

1. Pod 語(yǔ)義缺失

Kubernetes 的 CRI 規(guī)范強(qiáng)化了 Pod Sandbox 的概念，將 Pod 作為容器編排調(diào)度的最小單元。Pod 是一個(gè)或多個(gè)容器的組合，他們共享一些命名空間和資源，沙箱(Sandbox)則通過(guò)容器隔離技術(shù)為這一組容器提供安全隔離的運(yùn)行環(huán)境。然而，Pod 的語(yǔ)義在容器引擎和容器運(yùn)行時(shí)的層面并沒有很好的體現(xiàn)出來(lái)，這導(dǎo)致這些組件在架構(gòu)上的不合理，同時(shí)也增加了實(shí)現(xiàn)的復(fù)雜度，帶來(lái)了很多維護(hù)上的問(wèn)題，比如 shim 進(jìn)程的管理和維護(hù)，IO 通道的維護(hù)等等。

2. Shim 進(jìn)程的冗余

在通過(guò) shim v2 標(biāo)準(zhǔn)創(chuàng)建 Pod 的過(guò)程中，每創(chuàng)建一個(gè)新 Pod 都需要啟動(dòng)一個(gè) shim 進(jìn)程對(duì) Pod 及其資源進(jìn)行管理。由此而帶來(lái)的問(wèn)題有以下三點(diǎn)：

內(nèi)存資源的消耗：shim 進(jìn)程消耗了大量?jī)?nèi)存資源。經(jīng)過(guò)測(cè)試，在 Containerd + Kata 的組合中，每增加一個(gè) Pod，由于 shim 進(jìn)程引起的管理層組件的內(nèi)存消耗就增加了約 18MB。

啟動(dòng)時(shí)間的延長(zhǎng)：由于 shim 進(jìn)程的存在，容器生命周期管理的調(diào)用鏈變長(zhǎng)，增加了啟動(dòng)時(shí)間，消耗了更多的 CPU 資源。

可靠性問(wèn)題的增加：在大規(guī)模商用實(shí)踐中，可靠性問(wèn)題困擾著不少容器商用團(tuán)隊(duì)，這些問(wèn)題不僅影響了業(yè)務(wù)正常開展，而且難以定位和解決。shim 進(jìn)程的存在帶來(lái)了大量的類似問(wèn)題，比如狀態(tài)不一致、數(shù)據(jù)流卡死、進(jìn)程殘留等，大大增加了容器的維護(hù)成本。

3. Pause 容器的冗余

由于歷史原因，早期的通用容器是通過(guò) Linux 的 namespace + cgroups 實(shí)現(xiàn)資源隔離與資源限制的。Pause 容器就是早期的容器形態(tài)為了應(yīng)對(duì) CRI 中 Pod 語(yǔ)義而創(chuàng)建的特殊容器。這個(gè)容器的作用就是根據(jù)配置創(chuàng)建命名空間、限制共享資源。除此之外，Pause 容器不執(zhí)行任何實(shí)際工作但卻會(huì)消耗一些 CPU 時(shí)間和內(nèi)存資源，同時(shí)由于 Pause 容器的存在也增加了系統(tǒng)被攻擊的攻擊面，會(huì)帶來(lái)一些潛在的安全風(fēng)險(xiǎn)。事實(shí)上，對(duì)于當(dāng)前的一些容器隔離技術(shù)來(lái)說(shuō)，Pause 容器是可以消除的。比如說(shuō)虛擬化隔離技術(shù)，虛擬機(jī)本身就已經(jīng)具備了足夠的安全性與隔離性，不需要 Pause 容器協(xié)助配置命名空間和共享資源。

4. 容器運(yùn)行時(shí)隔離技術(shù)單一

容器隔離技術(shù)是推動(dòng)容器運(yùn)行時(shí)快速發(fā)展的主要?jiǎng)恿χ弧．?dāng)前主流的容器隔離技術(shù)有以下幾種：

Linux 容器隔離技術(shù)：Linux 容器主要采用 namespace + cgroups 的方式實(shí)現(xiàn)隔離，其主要特點(diǎn)是高性能、低開銷。LXC 是比較早期的隔離技術(shù)，后來(lái)由于其安全性和可移植性的問(wèn)題，逐漸被 libcontainer 取代，但其隔離性一直較差，例如 runc 容器。

輕量級(jí)虛擬化容器隔離技術(shù)：MicroVM 是一種基于虛擬化的容器隔離技術(shù)，它使用了輕量級(jí)的虛擬化技術(shù)來(lái)實(shí)現(xiàn)容器的隔離，具備了傳統(tǒng)虛擬機(jī)的強(qiáng)隔離性和安全性，但帶來(lái)的效率問(wèn)題也頗為明顯，比如 QEMU， Stratovirt 等。

用戶態(tài)內(nèi)核隔離技術(shù)：用戶態(tài)內(nèi)核是將原來(lái)運(yùn)行在內(nèi)核態(tài)的大部分內(nèi)核功能運(yùn)行在用戶態(tài)，通過(guò)對(duì)業(yè)務(wù)進(jìn)程系統(tǒng)調(diào)用的代理實(shí)現(xiàn)系統(tǒng)調(diào)用的安全隔離。相比于虛擬化，用戶態(tài)內(nèi)核更加輕量化、性能更好，但由于依舊處于早期發(fā)展階段，其穩(wěn)定性、可靠性和兼容性存在不少問(wèn)題，比如 gVisor， Quark 等。

語(yǔ)言虛擬機(jī)隔離技術(shù)：語(yǔ)言虛擬機(jī)隔離技術(shù)本質(zhì)上是將底層字節(jié)碼通過(guò)專用的語(yǔ)言虛擬機(jī)來(lái)加載運(yùn)行，從而達(dá)到隔離的目的。Wasm 虛擬機(jī)就是語(yǔ)言虛機(jī)的一種。該類型語(yǔ)言虛擬機(jī)隔離技術(shù)利用與平臺(tái)無(wú)關(guān)的系統(tǒng)接口（WASI），使 Wasm 程序能夠訪問(wèn)到系統(tǒng)資源。Wasm 沙箱具備冷啟動(dòng)速度快、資源開銷小的有點(diǎn)，但目前的使用約束較多，支持的語(yǔ)言也有限，成熟度不高，目前還有很多尚未解決的隔離、通用性和語(yǔ)言生態(tài)問(wèn)題。

不同形態(tài)的容器隔離技術(shù)在性能、安全性以及通用性上都有各自的優(yōu)劣，當(dāng)下大部分容器運(yùn)行時(shí)都只支持單一容器隔離技術(shù)，無(wú)法很好地發(fā)揮不同隔離技術(shù)的優(yōu)勢(shì)。因此在單節(jié)點(diǎn)部署多形態(tài)沙箱的成本與復(fù)雜度都會(huì)比較高。

iSulad+Kuasar：新一代統(tǒng)一容器運(yùn)行時(shí)解決方案

為了解決上述的這些痛點(diǎn)問(wèn)題，openEuler 社區(qū)聯(lián)合華為云推出了新一代統(tǒng)一容器運(yùn)行時(shí)的解決方案，目標(biāo)是讓容器引擎和容器運(yùn)行時(shí)更加優(yōu)雅合理地解決由 shim v2 標(biāo)準(zhǔn)對(duì) Pod 生命周期及其資源管理而引起的問(wèn)題。

在容器隔離技術(shù)欣欣向榮的今天，業(yè)界對(duì)于將 Sandbox 語(yǔ)義引入容器引擎和容器運(yùn)行時(shí)的思考與討論一直在持續(xù)進(jìn)行。事實(shí)上，Containerd 社區(qū)早就開始了對(duì) Sandbox 語(yǔ)義引入的探討，Sandbox API[3]也于 2020 年 3 月被提出，2022 年 4 月正式被合入了 Containerd 社區(qū)。

雖然 Sandbox API 的合入使 Containerd 內(nèi)部對(duì)于 Pod 語(yǔ)義的處理更加清晰，但并不能夠解決上述其他與 shim 相關(guān)的問(wèn)題。iSulad 和 Kuasar 項(xiàng)目對(duì)于 Sandbox API 更深層次的創(chuàng)新為解決這些問(wèn)題帶來(lái)了可能性。在新的解決方案中，iSulad 作為容器引擎將 Sandbox API 的調(diào)用延伸出去，通過(guò) RPC 讓作為容器運(yùn)行時(shí)的 Kuasar 來(lái)管理 Pod。與原有的基于 shim v2 的方案不同，新的方案不需要為每個(gè) Pod 都創(chuàng)建一個(gè) shim 進(jìn)程。在新的架構(gòu)中，同一類型的容器只需要使用同一個(gè)進(jìn)程來(lái)管理。例如，上圖中的 MicroVM Sandboxer 就是用于管理輕量級(jí)虛擬機(jī)的進(jìn)程。iSulad 通過(guò) Sandbox API 與 MicronVM Sandboxer 進(jìn)行交互，用于管理所有該類型的 Pod 的生命周期。同時(shí)，每當(dāng)新的 Pod 被創(chuàng)建后，Pod 中的 Task Service 的地址就會(huì)通過(guò) Sandbox API 返回給 iSulad，iSulad 便可通過(guò) shim v2 接口與 Pod 中的 Task Service 進(jìn)行交互，管理 Pod 中的容器。

這個(gè)新的解決方案完美地解決了容器引擎與容器運(yùn)行時(shí)之間遺留已久的痛點(diǎn)問(wèn)題：

「Sandbox 的語(yǔ)義被帶入了容器引擎和容器運(yùn)行時(shí)」，在語(yǔ)義層面與 CRI 保持一致，增強(qiáng)了在云原生架構(gòu)上的連貫性。

Kuasar 用一個(gè) Sandboxer 進(jìn)程取代了 shim v2 中的多個(gè) shim 進(jìn)程，解決了由 shim 進(jìn)程帶來(lái)的多個(gè)問(wèn)題：

「Sandboxer 削減了 shim 進(jìn)程的冗余，大大減小了由于 shim 進(jìn)程帶來(lái)的資源開銷。根據(jù)測(cè)試在 50 個(gè) Pod 的場(chǎng)景下，Kuasar 在管理面的開銷只有 shim V2 的 1%?！?/p>

「容器的創(chuàng)建不需要通過(guò) shim 進(jìn)程代理，iSulad 直接將容器生命周期管理的請(qǐng)求發(fā)送給 Task Service，從而使啟動(dòng)時(shí)間縮短了 40%以上?！?/p>

「消除了 shim 進(jìn)程以后，各種狀態(tài)不一致、數(shù)據(jù)流卡死、進(jìn)程殘留等可靠性問(wèn)題都會(huì)隨之有所改善?！?/p>

在新的架構(gòu)中，Pod 是通過(guò) Sandbox API 創(chuàng)建，不必遵循 OCI 標(biāo)準(zhǔn)流程，從而「消除了 Pause 容器的冗余」。

新的解決方案「支持在單一節(jié)點(diǎn)上通過(guò)配置運(yùn)行多種不同類型的沙箱，利用不同的隔離技術(shù)，在性能、安全性及通用性等各方面形成優(yōu)勢(shì)互補(bǔ)」。

iSulad

作為用 C/C++編寫而成的容器引擎，iSulad 的內(nèi)存底噪僅為 Containerd 的 50%，其輕、靈、快的特點(diǎn)使其能夠在包括云原生、嵌入式等多種場(chǎng)景下部署使用。

在新的解決方案中，iSulad 在結(jié)構(gòu)上也針對(duì) Pod 的處理進(jìn)行了創(chuàng)新與調(diào)整：

北向接口：與原有使用 Container 的語(yǔ)義處理 Pod 管理請(qǐng)求的方式不同，iSulad 將 Sandbox 的語(yǔ)義引入了架構(gòu)和實(shí)現(xiàn)當(dāng)中，針對(duì) Pod 與 Container 進(jìn)行了語(yǔ)義上的區(qū)分，不僅更好地支持了 CRI 以及命令行對(duì)于 Pod 的請(qǐng)求，而且也為后續(xù)容器形態(tài)的多樣性提供了更大的拓展空間。

南向接口：iSulad 將 Sandbox API 延伸出去，通過(guò) Sandbox API 為不同的容器形態(tài)提供統(tǒng)一接口，實(shí)現(xiàn)歸一化管理，同時(shí)也對(duì)容器運(yùn)行時(shí) Kuasar 提供了更為清晰、精準(zhǔn)的調(diào)用請(qǐng)求。

用戶可以通過(guò) iSulad 的dev-sandbox 分支[4]，體驗(yàn) iSulad+Kuasar 的最新版本，具體可參見用戶指南[5]。

iSulad 社區(qū)將在未來(lái)對(duì)新一代容器運(yùn)行時(shí)的演進(jìn)中，持續(xù)與 Kuasar 社區(qū)保持深入合作，共同擴(kuò)大多沙箱容器技術(shù)在業(yè)界的影響力。

Kuasar

Kuasar[6]作為新一代的容器運(yùn)行時(shí)，不再采用通過(guò) shim v2 接口來(lái)管理 Pod，取而代之的是 Kuasar 向容器引擎提供的新一代容器運(yùn)行時(shí) Pod 管理接口 Sandbox API。這套接口不僅邏輯更加清晰，而且可以支持多沙箱接入。

Kuasar 的設(shè)計(jì)引入了 Sandboxer 的概念。每一種 Sandboxer 都使用了自己的容器隔離技術(shù)，用來(lái)管理同一類型的 Pod。當(dāng)前 Kuasar 已支持多種 Sandboxer 的實(shí)現(xiàn)，包括 QEMU，Cloud-Hypervisor，StratoVirt[7]，Quark 等。

openEuler 全棧解決方案

openEuler 社區(qū)在容器引擎和容器運(yùn)行時(shí)技術(shù)上的探索是多方位的。iSulad 項(xiàng)目已經(jīng)活躍多年，并在功能上持續(xù)完善，性能上持續(xù)優(yōu)化。輕量級(jí)虛擬機(jī) StratoVirt 則著力于虛擬技術(shù)的突破，相比于 QEMU 在內(nèi)存和啟動(dòng)時(shí)間上都有大量?jī)?yōu)化。如今，與華為云合作的新一代統(tǒng)一容器運(yùn)行時(shí) Kuasar 步入正軌，openEuler 社區(qū)具有了「iSulad + Kuasar + StratoVirt 全棧國(guó)產(chǎn)安全容器解決方案」。對(duì)比主流的 Containerd + Kata + QEMU 的解決方案，這套國(guó)產(chǎn)解決方案大大提升集群的整體性能和部署能力。

總結(jié)

新一代容器引擎與容器運(yùn)行時(shí)的解決方案解決了當(dāng)前主流方案由來(lái)已久的痛點(diǎn)問(wèn)題，不僅完善了運(yùn)行時(shí)在 Pod 語(yǔ)義上的缺憾，新增了多沙箱部署的能力，而且在性能和可靠性等方面也帶來(lái)了大幅提升。目前已完成了功能上開發(fā)，后續(xù)特性的探索與質(zhì)量的加固還在持續(xù)進(jìn)行當(dāng)中，歡迎大家提前試用并提出寶貴的意見，我們會(huì)盡快催熟相關(guān)特性并合入 openEuler LTS 版本。

openEuler 社區(qū)一直秉承著開放、合作、共享的開源態(tài)度，歡迎更多的開發(fā)人員加入 openEuler 參與 iSulad、Kuasar、StratoVirt 等容器和虛擬化項(xiàng)目共同探索。

審核編輯 ：李倩