理論+實操，帶你瞭解多沙箱容器執行時Kuasar
摘要：華為雲DTSE技術佈道師張天陽結合沙箱容器發展歷程，介紹華為雲多沙箱容器執行時 Kuasar 專案優勢，開啟多沙箱容器執行時上手實踐體驗。
本文分享自華為雲社群《理論+實操，帶你瞭解多沙箱容器執行時Kuasar》，作者：華為雲社群精選。
本期《多沙箱容器執行時Kuasar開發上手實踐》主題直播中，華為雲DTSE技術佈道師張天陽結合沙箱容器發展歷程，介紹華為雲多沙箱容器執行時 Kuasar 專案優勢，為開發者演示 Kuasar 的安裝執行方式，開啟多沙箱容器執行時上手實踐體驗。
順勢而出的沙箱容器
2013年，docker 橫空出世，雲端計算進入容器時代，所謂的容器也就是執行在宿主機上的程序，通過 Namespace 和 Cgroup 技術進行隔離和限制，和主機共用核心。
2014年，kubernetes 開源併成為主流的容器編排工具。在 kubernetes 中，Pod 是一個或多個容器的集合，容器間可以共用網路和儲存，為此引入了 pause 容器來實現這一特性。
「與宿主機系統共用核心的容器，是存在著巨大的安全隱患。」華為雲DTSE技術佈道師張天陽講到。
也正是看到這個問題，在2017年底，沙箱（Sandbox）容器技術興起，它將容器程序限制在一個封閉的沙箱環境中，防止其對系統和其他容器造成破壞，具有極高的安全性。
沙箱天然符合 Pod 的定義，它為一組容器提供了一個隔離的環境，在沙箱環境中執行的容器，就是沙箱容器。根據沙箱隔離的邊界可分為：
- 輕量虛擬機器器沙箱（MicroVM Sandbox）：在宿主機上模擬一套完整的虛擬機器器，容器執行在虛擬機器器內，具有非常高的安全隔離效果。
- 使用者態核心沙箱（Application Kernel Sandbox）：通過一個執行在使用者態的核心程式，攔截並實現容器的系統呼叫，從而保證容器間的安全隔離性。
- WebAssembly沙箱（Wasm Sandbox）：將容器執行在 WebAssembly 的執行時中，依賴 WebAssembly 的能力提供進程序級別的隔離。
每種沙箱在極速彈性、安全隔離和標準通用維度有各自的優勢，目前雲廠商都已在生產環境佈局了沙箱容器產品，每個沙箱藉助 containerd Shim v2 均實現了一套管理面的程式，彼此之間不相相容。
2023年3月，containerd 在其 v1.7.0 版本中釋出了 Sandbox API 特性，該特性提供了一套管理沙箱的API，它的出現使得容器和沙箱的概念解耦，「容器歸容器，沙箱歸沙箱」，建立 Pod 就是建立沙箱，不再需要藉助 pasue 容器。
沙箱容器已成為雲原生場景下的安全的解決方案，我們希望藉助 Sandbox API 的力量，實現一種支援多種沙箱技術的容器執行時。
然而單一容器隔離技術無法滿足使用者雲上業務對安全隔離、極速彈性、標準通用等多個維度的訴求。基於此，華為雲於2023 年 4 月在荷蘭阿姆斯特丹舉辦的 KubeCon + CloudNativeCon Europe 2023 雲原生峰會上正式開源Kuasar 。新開源的多沙箱容器執行時 Kuasar 可以充分利用節點資源、降本增效，為使用者提供更安全高效的沙箱場景解決方案。
Kuasar架構技術大揭祕
Kuasar 是一個多沙箱容器執行時，那麼什麼是容器執行時？簡單說容器執行時是一個負責拉起容器，管理容器執行狀態的執行時元件，可以分為高階容器執行時和低階容器執行時兩類：
- 高階容器執行時：負責 CRI 的實現，從高維度管理容器和映象範例，containerd, CRI-O, docker 還有 iSulad 都是典型的高階容器執行時。
- 低階容器執行時：負責 OCI 實現，真正操作容器。Kata-containers 和 runC 等都是低階容器執行時。
Kuasar 屬於低階容器執行時，和高階容器執行 containerd 互動，Kuasar 主要由兩個模組組成：
- Kuasar-Sandboxer：實現了 Sandbox API，負責管理沙箱生命週期和資源分配。Sandboxer 以外掛的形式和 containerd 互動。
- Kuasar-Task：實現了 Task API，負責管理容器的生命週期和資源分配。
MicroVM Sandboxer：虛機程序提供了完整的虛擬化層和 Linux 核心， vmm-sandboxer 負責建立虛機和呼叫 API， vmm-task 作為虛機裡的 init 程序負責拉起容器程序，容器的 IO 流則可通過虛機的 vsock 或 uds 匯出。
App Kernel Sandboxer： Quark 是一種新型的 App Kernel Sandbox，使用自己的 QVisor 作為 hypervisor 和自定義核心 QKernel。QVisor 只負責KVM虛擬機器器的生命週期管理，Qkernel 攔截所有的系統呼叫，並通知 QVisor 處理。quark-sandboxer 拉起 Qvisor 和 Qkernel，每當需要啟動容器時，QVisor 中的 quark-task 將呼叫 Qkernel 來啟動一個新的容器。同一 Pod 中的所有容器都將在同一個程序中執行。
Wasm Sandboxer：WebAssembly 沙箱定義了一套新的指令集和虛擬機器器。所有程式必須編譯成 Wasm 指令集才能在 Wasm 虛擬機器器中執行，因此對應用程式有很高的要求。wasm-sandboxer 和 wasm-task 為一個獨立的程序，每當需要在沙箱中啟動容器時，wasm-task 將 fork 一個新程序，啟動一個新的 WasmEdge runtime，並在其中執行 Wasm 程式碼。
Kuasar改變當前的Shim V2 的管理模型，帶來以下收益：
- sandbox 管理邏輯清晰：sandbox 管理邏輯和 container 管理邏輯完全分開，開發友好，語意清晰
- 簡化 container 呼叫鏈：取消 Task API 到 Shim v2 API 的轉化，直接呼叫，鏈路簡化
- 高效的sandboxer程序： Sandboxer 程序常駐減掉了冷啟動 Shim 程序的耗時， 1:N 管理模型大幅減少了程序數量，Rust 程式記憶體安全，相比 Golang 開銷小
- pause 容器消失：建立 Pod 不再建立 pause 容器，不再需要準備 pause 容器映象快照
為了更好地展現Kuasar 效能優勢，張天陽選擇 「端到端容器啟動時間」和「管理面元件記憶體消耗」作為衡量 Kuasar 效能的兩個指標，在保持環境變數一致的前提下和同類競品進行對比測試。
啟動時間測試分為兩組，一組統計單個 Pod 的啟動時間，另一組統計並行啟動50個 Pod 的時間：
Kuasar 100% 的啟動速度提升主要得益於兩方面，一方面是 Sandbox API 的實現，使得建立容器不再單獨建立 pause 容器，節省了準備pause容器映象快照的時間；另一方面得益於1:N 的管理模型，Sandboxer 程序常駐，從而節省了冷啟動 Shim 程序的時間，這使得容器的啟動速度大大提升。
記憶體消耗測試共分三輪，每輪分別啟動了1、5、10、20、30和50個Pod，查詢Sandboxer 程序和所有 Shim 程序的 PSS 數值。
Kuasar 節省近99%的記憶體，原因也可分為兩點：主要是 1:N 的管理模型使得 N 個程序減少為1個程序，帶來的記憶體收益與 Pod 數成正比；其次，Kuasar 採用了 Rust 程式語言，相比於 Kata Shim 程序使用的 Golang 語言，語言本身也會帶來一些記憶體收益。
五分鐘教你操作Kuasar
瞭解了Kuasar相關技能和特性，相信大家對產品有了一個大致的瞭解。接下來，就花幾分鐘帶大家從安裝上手，實際操作了解和認識Kuasar。
為了讓大家更好地體驗，在Kuasar安裝設定操作上，為大家準備了一指禪，如下：
- 方式一：Ubuntu 22.04 作業系統，可按照 Github Release 釋出說明直接下載安裝: https://github.com/kuasar-io/kuasar/releases/tag/v0.0.1-alpha1
- 方式二：如果是原始碼編譯，需要按照 README 裡的說明進行：https://github.com/kuasar-io/kuasar
溫馨小提醒，在安裝設定前需要大家預準備一下內容：
面向未來，作為一個開放和可延伸的 多沙箱容器執行時，Kuasar 將發揮沙箱介面的優勢，擁抱業界最新的 DRA(Dynamic Resource Allocation)、CDI(Container Device Interface) 等管理介面，為雲原生場景帶來更安全、高效、便捷的容器解決方案，為雲原生應用提供更安全的保障。