iSulad Sandbox API簡化容器調用鏈

背景

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

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

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

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

iSulad[5]也率先通過 Sandbox API 支持 Kuasar，提供高效和穩(wěn)定的沙箱管理能力。openEuler 23.09 完成對 iSulad+Kuasar+StratoVirt 的集成，為用戶提供了一個極速輕量的安全容器解決方案，具體可參見第二篇 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 的引入解決了容器引擎和容器運行時之間由來已久的痛點問題[2]：

引入 Sandbox 語義，增強了云原生架構上的連貫性

削減 shim 進程的冗余，減小資源開銷，加快啟動速度

縮短調用鏈，可靠性倍增

消除 Pause 容器冗余

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

生命周期與管理

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

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

資源管理

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

iSulad 新架構

圖1. iSulad 架構對比圖

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

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

沙箱與容器的解耦

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

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

沙箱控制器

圖2. 沙箱控制器類圖

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

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

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

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

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

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

簡化容器調用鏈

圖3. 容器啟動流程圖

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

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

總結

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

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

審核編輯：湯梓紅