文/雲原生 SIG （Special Interest Group）

一、Kata 的過去

讓我們將時鐘撥回 2015 年 5 月，Hyper.sh 和 Intel 開源技術中心的工程師們分別獨立釋出了runV 和 Clear Containers 的虛擬化容器專案，而這兩個專案便是 Kata Containers ¹ 的前身。這兩個專案互相有很多交流，在分別獨立發展了兩年半之後，於 2017 年底合併成了 Kata Containers 專案，並把這個專案捐給 Openstack 基金會管理，這也是 Openstack 基金會的第一個 Pilot 專案。在 2019 的 4 月，Kata Containers 被 Openstack 基金會認可為其第二個頂級專案，在這之前的十多年裡，Openstack 基金會都只有 Openstack 一個頂級專案。

Kata Containers 安全容器的誕生解決了許多普通容器場景無法解決的問題：

1. 多租戶安全保障。 雲原生多租戶場景下，安全容器可以防止惡意租戶對 host 核心的直接攻擊並大幅減少機器上其他租戶的風險，從而讓公有云服務變得更穩定。

2. 不同 SLO 混部容器混合部署。 安全容器的強隔離性減少了容器之間的效能影響，使得不同 SLO 優先順序例項混部有了更穩定的技術方案，對延時敏感的線上業務用 runC 解決方案，大資料類對資源訴求比較高且有明顯峰谷差異的離線業務用安全容器解決方案，防止離線業務突發流量影響到線上業務，透過線上離線業務同時混部進一步減少計算資源的浪費和成本消耗。

3. 可信&不可信容器混合部署。 可信程式碼執行在 runC 容器中，不可信程式碼執行在安全容器中，兩者在同一臺宿主機上混部，降低不可信容器產生危害的可能性。

在這些優勢的基礎上，安全容器在虛擬化上追求極致的輕薄，從而讓整體資源消耗和彈效能力接近 runC 容器方案，以此達到 Secure as VM、Fast as Container 的技術目標。

二、Kata 的發展

在 2018 年 5 月 Kata 1.x 階段， Kata 和 containerd 社群共同制定了 shimv2 介面規範，並率先在 Kata Containers 支援了該規範。18 年11月，透過 containerd-shim-v2 和 vsock 技術，Kata 精簡了大量的元件，配合輕量級 hypervisor 和精簡核心，kata 可以大幅降低記憶體開銷和容器啟動時間。 更關鍵的是， 降低系統部署複雜度還大幅提高了穩定性，特別是在系統過載情況下的穩定性。

（圖1 / Kata 1.x 架構圖）

2019 年的時候，Kata 從 1.x 升級到了 2.x , 有了非常重要的技術進步。Kata-agent 使用 Rust 進行了重構，極大程度減少了記憶體開銷以及整體攻擊面。

透過 2.x 版本，Kata 從最開始的做架構、用開源元件搭建原型的快速成長道路，逐漸有了名氣，走向了影響上游社群技術迭代的成熟道路。而 Kata 的整體架構在 2.x 版本中已趨向成熟，後續發展需要開始對專用元件進行思考和最佳化，從而以區域性影響整體來實現 Kata 能力的再次提升，例如 2.x 中用 Rust 改寫 Kata agent 降低記憶體開銷便是一個很好的例子。

而在 Kata 迅速發展的這幾年間，阿里雲內部有一個名為 “袋鼠” 的團隊一直在基於 Kata 打造雲原生場景下的秘密武器。

三、袋鼠雲原生底層系統

為了解決由於雲原生帶來的高密、高併發等技術難題，阿里雲內部用多年的時間錘鍊了一套袋鼠雲原生底層系統。袋鼠中的安全容器解決方案便是基於 Kata Containers 專案打造，並將其向更極致的方向深度最佳化，袋鼠做的最佳化諸如使用 Rust 重寫了 Kata Container 2.0 的 go runtime 來進一步降低容器執行時的記憶體開銷，並且為 Kata Container 專門開發了一個針對容器場景深度最佳化的輕量級虛擬機器管理器Dragonball，透過容器執行時以及虛擬機器一體的設計將 Kata 的整體體驗帶上了新的高度。

那麼袋鼠安全容器都能提供什麼樣的能力呢？

簡單來說便是極致的高密和彈性。

袋鼠安全容器可以在 6 秒之內彈出 3000 個安全容器 ，同時在一臺機器上可以執行 超過 4000 個以上的安全容器 。透過袋鼠，我們成功支撐了阿里雲的函式計算 FC 業務每日近 120 億呼叫量，彈性容器例項 ECI 業務每日最高超百萬的建立量，透過極致的效能表現大幅增加業務的核心競爭力。在極致效能之外，我們也透過使用安全容器進行混部，從而節省了大量資源成本。

袋鼠在內部取得的成績與 Kata 社群的發展息息相關，因而袋鼠也決定將其多年來內部打磨的系統回饋到 Kata 社群，共同推進 Kata 社群的進一步發展。

四、Kata 3.0：袋鼠與 Kata 的一場碰撞

在雲原生場景下，業界對容器啟動速度、資源消耗、穩定性的要求越來越高，而這些也是安全容器相對普通容器會面臨的挑戰。仿若多年前 runV 和 Clear Containers 的互動誕生了 Kata Containers 這個頂級專案，多年之後的今天袋鼠與 Kata 之間彼此碰撞，袋鼠會將其基於 Kata 社群歷經線上生產環境考驗的內部系統開源到 Kata 社群，助力 Kata 社群架構升級至 3.0 版本，讓 Kata 整體的使用體驗、資源消耗、啟動速度、穩定性都得到提升。

總結而言，在 Kata 3.0 版本中，我們將新增加了以下設計：

為了減少複雜的流程來和不同 VMM 適配，獲得開箱即用的安全容器體驗，我們提供了內建基於容器場景深度最佳化的 Dragonball 沙箱。 Dragonball 將提供 Kata 安全容器生態下的虛擬化最優解。

（當然，Kata 3.0 的可擴充套件架構也支援使用者透過配置選項使用其他 VMM，做出符合實際需求的決策。）

為了實現高效能、低資源利用、記憶體安全，以及高併發的目標，我們實現了 Async Rust Runtime 的新技術。
為了支援不同 Service、 Runtime 和 Hypervisor，以及增加機密容器的相關支援，為 Wasm 等未來方向留下空間，我們在 Runtime 內提供了可擴充套件框架來實現這一目標。
為了容器和沙箱資源生命週期統一管理機制，我們提供了 Resource Manager 機制來實現這一目標。

在本文的後續部分，我們會對 Kata 3.0 的重點更新進行展開。

五、設計介紹

（圖2 / Kata3.0 架構圖）

5.1 內建 VMM Dragonball

Dragonball 沙箱是針對 Kata 量身打造的一個基於 KVM 的輕量級 VMM，除了支援常規的 hypervisor 的功能以外，還針對容器工作負載做了一些最佳化：

基於 Nydus ² 開源專案的容器映象管理和映象加速服務
可擴充套件高效能的虛擬裝置驅動
低 CPU 記憶體開銷
單VM快速啟動時間，多VM快速併發啟動速度

為什麼需要內建 VMM？

（圖3 / Ka ta2.x版本Runtime與VMM架構示意圖）

如圖所示，在 Kata2.x 之前 Runtime 和 VMM 是獨立的程式。Runtime 程式會 fork VMM 程式並透過 RPC 進行互動。通常，程式之間的互動比程式內的互動會消耗更多的資源，從而會導致相對較低的效率。同時還要考慮資源運維成本，例如，在異常情況下進行資源回收時，任何程式的異常都必須被其他元件檢測到，並啟用相應的資源回收程式。如果有額外的過程存在，恢復變得更加困難。

並且，不同版本的 Kata 還需要考慮和不同版本的 VMM 的適配問題，可能 VMM 版本的落後或升級都會導致 Kata 適配上出現問題，需要使用者花費額外的精力來做版本和配置上的調整。

最後，即使安全容器已經成為了業界多 SLO 混部/公有云多租戶問題的標準解決方案，現在仍沒有任何一款 VMM 是定位於支援安全容器生態的。其他 VMM 都有各自不同領域的定位，例如 QEMU 能力全面但程式碼已早早超越百萬行，整體啟動速度與消耗資源都偏大；Firecracker 雖然做到了極致輕薄但許多虛擬化能力都為了輕薄而做了減法，無法撐起安全容器複雜多變的場景需求。

多程式互動問題、運維複雜問題、VMM 版本適配問題、安全容器虛擬化缺位問題，都指向了一個共同的答案——我們需要一個專注於安全容器場景的 VMM 來提供安全容器生態下的虛擬化最優解。Dragonball VMM 便是帶著這個使命而來的，在 Kata3.0 裡，我們將提出一個內建於 Kata 生態的 Dragonball VMM，未來將與Kata 共同成長，以解決上文提到的這些歷史問題。後續我們也會有專項文章對 Dragonball 進行介紹，敬請期待。

如何支援內建 VMM？

我們提供了 Dragonball 沙箱，透過將 VMM 的功能整合到 Rust 庫中來啟用內建的 VMM。我們可以透過使用該庫來執行與 VMM 相關的功能。因為 Runtime 和 VMM 在同一個程式中，所以在訊息處理速度和 API 同步方面具備優勢。同時還可以保證 Runtime 和 VMM 生命週期的一致性，減少資源回收和異常處理維護，如圖 4：

（圖4 / Kata3.0 內建VMM示意圖）

5.2 可擴充套件框架

Rust 版本的 kata-runtime 為 Service、Runtime 和 Hypervisor 提供了可擴充套件框架，還包括了針對不同場景的配置邏輯。

在 API 層面，Service 提供了外掛註冊的機制來支援多種容器相關的原生服務。除了對容器程式進行管理的 task service, 後續還會增加 image 服務，以及可以支援運維監控的其他服務。
支援不同型別的 Runtime 。包括基於虛擬化技術的 VirtContainer，基於可信計算硬體的機密容器。後面還會根據 kata 社群和行業需求考慮支援 WasmContainer 以及 LinuxContainer。
對於 VirtContainer 支援的 Hypervisor，除了內建的 Dragonball, 也可以外掛式的去配置 Dragonball、Qemu、Acrn 以及 Firecracker。

5.3 資源管理

在我們的案例中，會有各種資源，每個資源都有相應的子型別。特別是對於 Virt-Container，每個子型別的資源都有不同的操作。並且可能存在依賴關係，例如 share-fs rootfs 和 share-fs volume 將使用 share-fs 資源將檔案共享到 VM。目前，network 和 share-fs 被視為沙箱資源，而 rootfs、 volume 和 cgroup 被視為容器資源。因此，我們為每個資源抽象了一個公共介面，並使用子類操作來對應不同子型別之間的差異。

5.4 Rust Async Runtime

相對於 Go 語言， Rust 在效能和資源消耗方面更勝一籌，在某些特定的場景下效率甚至優於 C++。同時， Rust 還能避免空指標，野指標，記憶體洩露，記憶體越界等一些列記憶體安全問題, 從而大幅減少了程式崩潰的頻率，這些能力對於 Kata 這種偏底層的系統尤為重要。然而，Go 語言的優勢在於內建的機制和庫來支援編寫併發程式，比如 goroutine，以此顯著降低 CPU 和記憶體開銷，尤其是對於具有大量 I/O 密集型任務的工作負載。我們為了既兼顧 Go 語言的併發和非同步優勢，又獲得 Rust 的安全性和低開銷特點，開發了 Async Rust Runtime。

如何支援 Async？

kata-runtime 由 TOKIO_RUNTIME_WORKER_THREADS 控制執行 OS 執行緒，預設為 2 個執行緒。對於TTRPC 和容器相關執行緒統一執行在 tokio 執行緒中，相關依賴需要切換到 Async，比如 Timer、File、Netlink 等。藉助 Async 我們可以輕鬆支援 non-block io 和計時器。目前，我們僅將 Async 用於 kata-runtime。內建的 VMM 保留了 OS 執行緒, 這樣可以確保執行緒是可控的。

六、何為開箱即用？

讓我們將注意力拉回到本文的標題——開箱即用的安全容器體驗。透過上文的介紹，我們提到的“開箱即用”也應該在讀者的心中逐漸清晰，在此我們對這個概念做以下總結：

透過提供內建於 Kata Runtime 的 Dragonball VMM 讓安全容器整體生態的底層基礎設施實現閉環，提供可擴充套件 Rust Runtime 來支援諸如機密容器等不同安全容器形態。從此之後，使用者無需再做複雜的適配工作，只需下載 Kata、編譯 Kata 即可執行 Kata，一切都將變得如此簡單和易用。

這樣開箱即用的體驗，無論是對於初入 Kata 想快速上手的小白，還是商用 Kata 的工程師團隊，都會帶來易用性、可維護性、穩定性等多方面的提升飛躍，任何技術的發展一定是向更純粹、更精簡的方向前進，因而我們也堅信這會是 Kata 安全容器生態未來的方向。

七、未來展望

7.1 Kata 3.0 開發路線

目前， Kata 3.0 還處於第一階段的開發，第一階段將會完成 Kata 基本功能的實現。剩餘的功能將會在第二和第三階段陸續支援，預計在 2022-07-25 會有 Kata 3.0 的第一個 alpha 版本，歡迎各位參與到 Kata 3.0 的建設以及試用 3.0 版本。

Class	Sub-Class	Development Stage
service	task service	階段 1
	extend service	階段 3
	image service	階段 3
runtime handler	Virt-Container	階段 1
	Wasm-Container	階段 3
	Linux-Container	階段 3
Endpoint	Veth Endpoint	階段 1
	Physical Endpoint	階段 2
	Tap Endpoint	階段 2
	Tuntap Endpoint	階段 2
	IPVlan Endpoint	階段 3
	MacVlan Endpoint	階段 3
	MacVtap Endpoint	階段 3
	VhostUserEndpoint	階段 3
Network Interworking Model	Tc filter	階段 1
	Route	階段 1
	MacVtap	階段 3
Storage	virtiofs	階段 1
Storage	nydus	階段 2
hypervisor	Dragonball	階段 1
	Qemu	階段 2
	Acrn	階段 3
	CloudHypervisor	階段 3
	Firecracker	階段 3

7.2 Kata 3.0 釋出時間

預計 2022-07-25 在 main 分支有可用的 alpha 版本，在此之前可先在開發分支 runtime-rs 使用 Kata 3.0。Kata 3.0 後續規劃的釋出時間與版本迭代進展我們也在此同步給各位。歡迎持續關注龍蜥社群公眾號及龍蜥雲原生 SIG，也歡迎感興趣的小夥伴參與共建。

2022-07-25	pre-release 3.0.0-alpha0
2022-08-15	pre-release 3.0.0-alpha1
2022-08-29	pre-release 3.0.0-alpha2
2022-09-12	pre-release 3.0.0-rc0
2022-09-26	pre-release 3.0.0-rc1
2022-10-10	release 3.0.0

龍蜥雲原生 SIG

在龍蜥雲原生的首次 SIG 會議上，我們的架構師詳細介紹了 Kata 3.0 原型 RunD 的技術架構，影片回放已上線至龍龍蜥社群官網和 B 站，歡迎對 Kata 3.0 想了解更多的小夥伴點選以下連結觀看：

官網：

B 站：

同時，雲原生 SIG 將整合龍蜥社群的雲原生優勢能力，輸出開箱即用的龍蜥雲原生髮行版，結合使用者需求輸出大資料、混部等場景的解決方案，協助使用者能更快更好使用雲原生技術構建應用叢集。Kata 作為龍蜥雲原生的專案之一，未來也將共同構建基於安全容器的雲原生服務。

後續 Kata 的能力我們會透過龍蜥社群雲原生 SIG 上在整個雲原生生態的視角上進行支援，歡迎感興趣的同學們掃碼加入龍蜥社群雲原生 SIG 群，一起共建雲原生生態。

多年錘鍊，邁向Kata 3.0 ！走進開箱即用的安全容器體驗之旅| 龍蜥技術