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

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

背景與現(xiàn)狀

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

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

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

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

1. Pod 語義缺失

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

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

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

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

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

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

3. Pause 容器的冗余

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「Sandboxer 削減了 shim 進(jìn)程的冗余，大大減小了由于 shim 進(jìn)程帶來的資源開銷。根據(jù)測試在 50 個 Pod 的場景下，Kuasar 在管理面的開銷只有 shim V2 的 1%。」

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

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

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

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

iSulad

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

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

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

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

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

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

Kuasar

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

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

openEuler 全棧解決方案

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

總結(jié)

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

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

審核編輯 ：李倩