背景

沙箱隔離技術(shù)是一種將進(jìn)程隔離到獨(dú)立環(huán)境中運(yùn)行的技術(shù)，可以有效地隔離進(jìn)程間的相互影響，提高系統(tǒng)的安全性。隨著容器技術(shù)的興起，沙箱隔離技術(shù)也在云原生領(lǐng)域中得到了廣泛的應(yīng)用。例如容器編排組件 Kubernetes 的最小編排調(diào)度單元 Pod Sandbox 實(shí)際上是一個(gè)沙箱，為其中的容器提供了資源共享和安全隔離的運(yùn)行環(huán)境。

然而，由于容器技術(shù)的歷史原因，沙箱的概念在容器引擎和容器運(yùn)行時(shí)中沒有得到足夠的支持。OCI 標(biāo)準(zhǔn)[1]未定義沙箱管理，導(dǎo)致容器引擎和容器運(yùn)行時(shí)只能采用容器管理的方式管理沙箱，引發(fā)性能和穩(wěn)定性問題，具體可參見第一篇 Kuasar 系列文章[2]。

事實(shí)上，容器領(lǐng)域一直在深入研究和探索引入沙箱管理接口的問題。舉例來說，Containerd 社區(qū)于 2022 年 4 月將 Sandbox API 相關(guān)功能整合到主線[3]，這一舉措對 Containerd 內(nèi)部沙箱管理邏輯進(jìn)行了優(yōu)化。然而，令人遺憾的是，它依然使用 OCI 標(biāo)準(zhǔn)接口來調(diào)用容器運(yùn)行時(shí)以管理沙箱。

2023 年 4 月 21 日，華為在 Kubecon+CloudNativeCon Europe 2023 云原生峰會上發(fā)布了多沙箱運(yùn)行時(shí) Kuasar[4]，將沙箱管理邏輯引入了容器運(yùn)行時(shí)。至此，Kuasar 成為第一個(gè)支持 Sandbox API 的容器運(yùn)行時(shí)。容器引擎使用 Sandbox API 直接管理沙箱成為了可能。

iSulad[5]也率先通過 Sandbox API 支持 Kuasar，提供高效和穩(wěn)定的沙箱管理能力。openEuler 23.09 完成對 iSulad+Kuasar+StratoVirt 的集成，為用戶提供了一個(gè)極速輕量的安全容器解決方案，具體可參見第二篇 Kuasar 系列文章[6]。

Sandbox API 簡介

service Controller {
    rpc Create(ControllerCreateRequest) returns (ControllerCreateResponse);
    rpc Start(ControllerStartRequest) returns (ControllerStartResponse);
    rpc Platform(ControllerPlatformRequest) returns (ControllerPlatformResponse);
    rpc Prepare(PrepareRequest) returns (PrepareResponse);
    rpc Purge(PurgeRequest) returns (PurgeResponse);
    rpc UpdateResources(UpdateResourcesRequest) returns (UpdateResourcesResponse);
    rpc Stop(ControllerStopRequest) returns (ControllerStopResponse);
    rpc Wait(ControllerWaitRequest) returns (ControllerWaitResponse);
    rpc Status(ControllerStatusRequest) returns (ControllerStatusResponse);
    rpc Shutdown(ControllerShutdownRequest) returns (ControllerShutdownResponse);
}

Sandbox API 的引入解決了容器引擎和容器運(yùn)行時(shí)之間由來已久的痛點(diǎn)問題[2]：

引入 Sandbox 語義，增強(qiáng)了云原生架構(gòu)上的連貫性

削減 shim 進(jìn)程的冗余，減小資源開銷，加快啟動(dòng)速度

縮短調(diào)用鏈，可靠性倍增

消除 Pause 容器冗余

統(tǒng)一沙箱接口使容器運(yùn)行時(shí)支持多沙箱

生命周期與管理

Sandbox API[7] 定義了容器引擎如何與容器運(yùn)行時(shí)交互，其中 Controller Service 定義了沙箱的生命周期管理接口，包括創(chuàng)建 (Create) 、啟動(dòng) (Start) 、停止 (Stop) 、等待退出 (Wait) 、狀態(tài)查詢 (Status) 、銷毀 (Shutdown) 、平臺信息查詢 (Platform) 等。

通過 Sandbox API，容器引擎能夠直接對沙箱進(jìn)行管理，無需通過 OCI 標(biāo)準(zhǔn)接口間接管理沙箱，提高了容器引擎的性能和穩(wěn)定性。

資源管理

Sandbox API 還定義了沙箱的資源管理接口，包括資源準(zhǔn)備 (Prepare) 、資源清理 (Purge) 、資源更新 (UpdateResources) 等。容器引擎可以通過這些接口管理容器資源，例如在創(chuàng)建容器前準(zhǔn)備資源，運(yùn)行過程中更新資源，容器退出后清理資源。

iSulad 新架構(gòu)

圖1. iSulad 架構(gòu)對比圖

在 Kuasar 發(fā)布以后，iSulad 第一時(shí)間采用了新的架構(gòu)以支持 Sandbox API ，使得它能夠通過 Kuasar 來直接管理沙箱。

為保持已有版本的兼容性與穩(wěn)定性，iSulad 只對 CRI V1 版本進(jìn)行了重構(gòu)升級，支持用戶使用 Sandbox API 管理沙箱。CRI V1alpha 版本繼續(xù)沿用 OCI 標(biāo)準(zhǔn)來處理沙箱管理請求。

沙箱與容器的解耦

在新的架構(gòu)中，iSulad 引入了 Sandbox 的語義，新增核心模塊 Sandbox ，使其成為容器引擎的一等公民，實(shí)現(xiàn)了容器管理與沙箱管理的解耦。從云原生整體架構(gòu)的角度看，容器編排組件、容器引擎和容器運(yùn)行時(shí)之間的沙箱管理變得更加流暢和高效，形成了一個(gè)完整的沙箱管理鏈路。

以 iSulad+Kuasar+StratoVirt 極速輕量的安全容器解決方案為例，iSulad 在北向接收來自 Kubernetes 的 CRI 請求，并創(chuàng)建 Sandbox 對象來處理 PodSandbox 相關(guān)調(diào)用，同時(shí)使用 Executor 模塊來處理 CRI 的 Container 請求。在南向，使用 Controller 模塊通過 Sandbox API 調(diào)用 Kuasar 的 Sandboxer 進(jìn)程來管理沙箱，同時(shí)使用 Runtime 中的 Shim V2 模塊來調(diào)用 Kuasar 的 Task 進(jìn)程，實(shí)現(xiàn)了對 StratoVirt 虛擬機(jī)中容器的管理。

沙箱控制器

圖2. 沙箱控制器類圖

Sandbox API 的實(shí)現(xiàn)使 iSulad 能夠直接通過 Controller 來管理沙箱，因此 Kuasar 容器運(yùn)行時(shí)也無需創(chuàng)建 Pause 容器以兼容 OCI 標(biāo)準(zhǔn)，避免了 Pause 容器的冗余。

在新架構(gòu)中，Controller 模塊的設(shè)計(jì)充分考慮了對原有沙箱管理功能的兼容性，即支持用戶通過Sandbox 和 Controller 模塊創(chuàng)建普通容器(Pause 容器)作為沙箱。

如上圖所示，Controller 模塊對 Sandbox 提供了統(tǒng)一 Controller 接口，以及兩種不同的實(shí)現(xiàn)：Sandboxer Controller 和 Shim Controller 。

Sandboxer Controller 是對 Sandbox API 的封裝，將用戶對沙箱的管理請求通過 gRPC 接口轉(zhuǎn)發(fā)給 Kuasar 的 Sandboxer 進(jìn)程，從而使 Sandboxer 執(zhí)行底層的沙箱管理邏輯。

Shim Controller 兼容原有的基于容器管理的接口，將對 Sandbox 的管理請求轉(zhuǎn)發(fā)給 Executor 模塊，以便創(chuàng)建和管理基于 Pause 容器的沙箱。Shim Controller 的實(shí)現(xiàn)使用戶能夠在新的架構(gòu)下繼續(xù)使用 OCI 標(biāo)準(zhǔn)接口來管理沙箱，以兼容原有已部署的業(yè)務(wù)，確保功能的連續(xù)性。

Sandbox 和 Controller 的詳細(xì)設(shè)計(jì)可以參見 iSulad 社區(qū)的設(shè)計(jì)文檔[8]。

簡化容器調(diào)用鏈

圖3. 容器啟動(dòng)流程圖

在支持了 Sandbox API 以后，iSulad 的容器管理流程也發(fā)生了一些變化。上圖以 iSulad+Kuasar+StratoVirt 解決方案為例，展示了 iSulad 從啟動(dòng)沙箱到啟動(dòng)容器的簡化流程。

在圖中，Kuasar Task 充當(dāng)虛擬機(jī)中的 init 進(jìn)程，同時(shí)也是虛擬機(jī)沙箱內(nèi)容器的管理進(jìn)程。它向 iSulad 提供容器管理接口 Task API ，當(dāng)前解決方案中的 Task API 接口的實(shí)現(xiàn)與 Shim V2 類似但又不完全相同。根據(jù) Shim V2 規(guī)范，容器引擎會調(diào)用一個(gè) Shim V2 的二進(jìn)制，創(chuàng)建 Shim 進(jìn)程并返回 Shim 地址，用于管理沙箱、容器和資源。然而，通過調(diào)用 Sandbox API，iSulad 不再需要通過 Shim 進(jìn)程來管理沙箱。相反，Sandbox API 的 Start 接口會在啟動(dòng)沙箱后返回一個(gè) Task 地址，使 iSulad 能夠與虛擬機(jī)中的 Kuasar Task 進(jìn)程直接通信，以管理容器的生命周期。這種設(shè)計(jì)消除 Shim 進(jìn)程以減少了管理面的內(nèi)存開銷并縮短調(diào)用鏈，從而提高了整個(gè)解決方案的性能和穩(wěn)定性。

總結(jié)

Sandbox API 是 iSulad、Kuasar 和 StratoVirt 這三個(gè)組件構(gòu)成的極速輕量的安全容器解決方案的核心紐帶。通過 Sandbox API，容器引擎能夠直接對沙箱進(jìn)行管理，無需通過 OCI 標(biāo)準(zhǔn)接口間接管理沙箱，從而顯著提高了容器引擎的性能和穩(wěn)定性。Sandbox API 的引入，也為容器引擎和容器運(yùn)行時(shí)之間的沙箱管理提供了一個(gè)標(biāo)準(zhǔn)化的接口，為容器領(lǐng)域的發(fā)展提供了新的可能性。當(dāng)前 Sandbox API 的實(shí)現(xiàn)已經(jīng)合入了 iSulad 社區(qū)的主線，用戶可以通過 openEuler 23.09 體驗(yàn)這一全棧自研的極速輕量安全容器解決方案，具體可參見 Kuasar 系列文章[6]。

openEuler 社區(qū)一直秉承開放、協(xié)作、共贏的理念，歡迎更多的開發(fā)者參與到 iSulad、Kuasar 和 StratoVirt 的建設(shè)中來，共同推動(dòng)容器領(lǐng)域的繁榮發(fā)展。

審核編輯：湯梓紅