iSulad+Kuasar：管理面資源消耗銳減99%的新一代統一容器運行時解決方案

隨著云計算和容器技術的不斷發展，容器引擎和容器運行時已經成為了云原生時代的基石，它們負責了容器生命周期的管理以及容器運行過程中環境的創建和資源的配置。openEuler 社區基于容器引擎項目 iSulad[1]在解決容器運行效率、安全性以及隔離性等問題上進行著不斷地嘗試與探索。

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

背景與現狀

從容器編排組件 Kubernetes 的視角來看，能夠處理 CRI(Container Runtime Interface)請求的服務端都是容器運行時(Container Runtime)。事實上，容器運行時還可以再細分為兩個層次，即容器引擎和底層容器運行時。

容器引擎(Container Engine)主要負責容器運行環境的創建、容器資源的配置和容器生命周期的管理，北向接收來自于 Kubernetes 或前端命令行的輸入，南向則調用底層容器運行時(Low Level Container Runtime)來完成最終容器環境的生成和容器生命周期的操作。

在業界，容器引擎和容器運行時的術語經常被交替使用?！冈诒疚牡恼Z義中，容器運行時特指底層容器運行時」。除了 iSulad 以外，當前的容器引擎還包括 Containerd，Docker 等，底層容器運行時包括 runc，Kata-Containers 等。

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

1. Pod 語義缺失

Kubernetes 的 CRI 規范強化了 Pod Sandbox 的概念，將 Pod 作為容器編排調度的最小單元。Pod 是一個或多個容器的組合，他們共享一些命名空間和資源，沙箱(Sandbox)則通過容器隔離技術為這一組容器提供安全隔離的運行環境。然而，Pod 的語義在容器引擎和容器運行時的層面并沒有很好的體現出來，這導致這些組件在架構上的不合理，同時也增加了實現的復雜度，帶來了很多維護上的問題，比如 shim 進程的管理和維護，IO 通道的維護等等。

2. Shim 進程的冗余

在通過 shim v2 標準創建 Pod 的過程中，每創建一個新 Pod 都需要啟動一個 shim 進程對 Pod 及其資源進行管理。由此而帶來的問題有以下三點：

內存資源的消耗：shim 進程消耗了大量內存資源。經過測試，在 Containerd + Kata 的組合中，每增加一個 Pod，由于 shim 進程引起的管理層組件的內存消耗就增加了約 18MB。

啟動時間的延長：由于 shim 進程的存在，容器生命周期管理的調用鏈變長，增加了啟動時間，消耗了更多的 CPU 資源。

可靠性問題的增加：在大規模商用實踐中，可靠性問題困擾著不少容器商用團隊，這些問題不僅影響了業務正常開展，而且難以定位和解決。shim 進程的存在帶來了大量的類似問題，比如狀態不一致、數據流卡死、進程殘留等，大大增加了容器的維護成本。

3. Pause 容器的冗余

由于歷史原因，早期的通用容器是通過 Linux 的 namespace + cgroups 實現資源隔離與資源限制的。Pause 容器就是早期的容器形態為了應對 CRI 中 Pod 語義而創建的特殊容器。這個容器的作用就是根據配置創建命名空間、限制共享資源。除此之外，Pause 容器不執行任何實際工作但卻會消耗一些 CPU 時間和內存資源，同時由于 Pause 容器的存在也增加了系統被攻擊的攻擊面，會帶來一些潛在的安全風險。事實上，對于當前的一些容器隔離技術來說，Pause 容器是可以消除的。比如說虛擬化隔離技術，虛擬機本身就已經具備了足夠的安全性與隔離性，不需要 Pause 容器協助配置命名空間和共享資源。

4. 容器運行時隔離技術單一

容器隔離技術是推動容器運行時快速發展的主要動力之一。當前主流的容器隔離技術有以下幾種：

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

輕量級虛擬化容器隔離技術：MicroVM 是一種基于虛擬化的容器隔離技術，它使用了輕量級的虛擬化技術來實現容器的隔離，具備了傳統虛擬機的強隔離性和安全性，但帶來的效率問題也頗為明顯，比如 QEMU， Stratovirt 等。

用戶態內核隔離技術：用戶態內核是將原來運行在內核態的大部分內核功能運行在用戶態，通過對業務進程系統調用的代理實現系統調用的安全隔離。相比于虛擬化，用戶態內核更加輕量化、性能更好，但由于依舊處于早期發展階段，其穩定性、可靠性和兼容性存在不少問題，比如 gVisor， Quark 等。

語言虛擬機隔離技術：語言虛擬機隔離技術本質上是將底層字節碼通過專用的語言虛擬機來加載運行，從而達到隔離的目的。Wasm 虛擬機就是語言虛機的一種。該類型語言虛擬機隔離技術利用與平臺無關的系統接口（WASI），使 Wasm 程序能夠訪問到系統資源。Wasm 沙箱具備冷啟動速度快、資源開銷小的有點，但目前的使用約束較多，支持的語言也有限，成熟度不高，目前還有很多尚未解決的隔離、通用性和語言生態問題。

不同形態的容器隔離技術在性能、安全性以及通用性上都有各自的優劣，當下大部分容器運行時都只支持單一容器隔離技術，無法很好地發揮不同隔離技術的優勢。因此在單節點部署多形態沙箱的成本與復雜度都會比較高。

iSulad+Kuasar：新一代統一容器運行時解決方案

為了解決上述的這些痛點問題，openEuler 社區聯合華為云推出了新一代統一容器運行時的解決方案，目標是讓容器引擎和容器運行時更加優雅合理地解決由 shim v2 標準對 Pod 生命周期及其資源管理而引起的問題。

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

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

這個新的解決方案完美地解決了容器引擎與容器運行時之間遺留已久的痛點問題：

「Sandbox 的語義被帶入了容器引擎和容器運行時」，在語義層面與 CRI 保持一致，增強了在云原生架構上的連貫性。

Kuasar 用一個 Sandboxer 進程取代了 shim v2 中的多個 shim 進程，解決了由 shim 進程帶來的多個問題：

「Sandboxer 削減了 shim 進程的冗余，大大減小了由于 shim 進程帶來的資源開銷。根據測試在 50 個 Pod 的場景下，Kuasar 在管理面的開銷只有 shim V2 的 1%?！?/p>

「容器的創建不需要通過 shim 進程代理，iSulad 直接將容器生命周期管理的請求發送給 Task Service，從而使啟動時間縮短了 40%以上?！?/p>

「消除了 shim 進程以后，各種狀態不一致、數據流卡死、進程殘留等可靠性問題都會隨之有所改善?！?/p>

在新的架構中，Pod 是通過 Sandbox API 創建，不必遵循 OCI 標準流程，從而「消除了 Pause 容器的冗余」。

新的解決方案「支持在單一節點上通過配置運行多種不同類型的沙箱，利用不同的隔離技術，在性能、安全性及通用性等各方面形成優勢互補」。

iSulad

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

在新的解決方案中，iSulad 在結構上也針對 Pod 的處理進行了創新與調整：

北向接口：與原有使用 Container 的語義處理 Pod 管理請求的方式不同，iSulad 將 Sandbox 的語義引入了架構和實現當中，針對 Pod 與 Container 進行了語義上的區分，不僅更好地支持了 CRI 以及命令行對于 Pod 的請求，而且也為后續容器形態的多樣性提供了更大的拓展空間。

南向接口：iSulad 將 Sandbox API 延伸出去，通過 Sandbox API 為不同的容器形態提供統一接口，實現歸一化管理，同時也對容器運行時 Kuasar 提供了更為清晰、精準的調用請求。

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

iSulad 社區將在未來對新一代容器運行時的演進中，持續與 Kuasar 社區保持深入合作，共同擴大多沙箱容器技術在業界的影響力。

Kuasar

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

Kuasar 的設計引入了 Sandboxer 的概念。每一種 Sandboxer 都使用了自己的容器隔離技術，用來管理同一類型的 Pod。當前 Kuasar 已支持多種 Sandboxer 的實現，包括 QEMU，Cloud-Hypervisor，StratoVirt[7]，Quark 等。

openEuler 全棧解決方案

openEuler 社區在容器引擎和容器運行時技術上的探索是多方位的。iSulad 項目已經活躍多年，并在功能上持續完善，性能上持續優化。輕量級虛擬機 StratoVirt 則著力于虛擬技術的突破，相比于 QEMU 在內存和啟動時間上都有大量優化。如今，與華為云合作的新一代統一容器運行時 Kuasar 步入正軌，openEuler 社區具有了「iSulad + Kuasar + StratoVirt 全棧國產安全容器解決方案」。對比主流的 Containerd + Kata + QEMU 的解決方案，這套國產解決方案大大提升集群的整體性能和部署能力。

總結

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

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

審核編輯 ：李倩