eBPF 和 Wasm：探索服務網(wǎng)格數(shù)據(jù)平面的未來

本文翻譯自 Vivian Hu 的 《eBPF and Wasm: Exploring the Future of the Service Mesh Data Plane》^[1]。

在 2021 年 12 月 2 日，Cilium 項目宣布了 Cilium Service Mesh^[2] 項目的測試版。在 2020 年 8 月 Google Cloud 宣布基于 eBPF 的 Google Kubernetes 服務（GKS）的數(shù)據(jù)平面 V2 的一年后，Cilium Service Mesh 帶來了 “無邊車服務網(wǎng)格”（sidecarless service mesh）的想法。它擴展了 Cilium eBPF 產(chǎn)品來處理服務網(wǎng)格中的大部分邊車代理功能，包括 7 層路由和負載均衡、TLS 終止、訪問策略、健康檢查、日志和跟蹤，以及內(nèi)置的 Kubernetes Ingress。

Cilium 的創(chuàng)始人 Isovalent 在一篇名為 “How eBPF will solve Service Mesh - Goodbye Sidecars^[3]” 的文章中解釋了 eBPF 如何替代邊車代理。

它將我們從邊車模型中解放處理，并允許我們將現(xiàn)有的代理技術集成到現(xiàn)有的內(nèi)核命名空間概念中，使其成為日常使用的優(yōu)雅容器抽象的一部分。

簡而言之，eBPF 承諾會解決服務網(wǎng)格中的重要痛點 -- 當有許多細粒度微服務時的性能損耗。然而，使用 eBPF 替換邊車代理這種新穎的想法，也存在著爭議。

服務網(wǎng)格中的數(shù)據(jù)平面是指管理數(shù)據(jù)流量如何路由和服務之間的流轉的基礎設施服務。目前，這是通過使用服務代理實現(xiàn)的。這種設計模式也通常被稱為邊車模式。邊車允許其附加的微服務透明地向服務網(wǎng)格中的其他組件發(fā)送和接收請求。

邊車通常包含了 7 層代理，比如 Envoy^[4]、Linkerd^[5] 或者 MOSN^[6]。該代理處理流量的路由、負載均衡、健康檢查、身份驗證、授權、加密、日志、跟蹤和統(tǒng)計數(shù)據(jù)收集。邊車還可以包含一個基于 SDK 的應用程序框架（比如 Dapr）以提供網(wǎng)絡代理以外的應用程序服務。此類服務的示例還包含了服務注冊、服務發(fā)現(xiàn)、資源綁定、基于名稱的服務調(diào)用、狀態(tài)管理、actor 框架 和密鑰存儲。

邊車代理通常在 Kubernetes Pod 或者容器中運行。微服務應用也同樣運行在容器內(nèi)，并通過網(wǎng)絡接口連接到邊車。然而，這些容器化應用程序的一個重要問題就是資源消耗。邊車服務隨著微服務的數(shù)量幾何級增長。當應用程序有數(shù)百個互聯(lián)和負載均衡的微服務時，開銷變得難以接受。服務網(wǎng)格代理商開始了性能上的競爭。正如 Infoq 之前報道的那樣^[7]，Linkerd 將其 Go 寫的代理用 Rust 重寫了，并獲得了顯著的性能提升。

并不奇怪，現(xiàn)有的服務網(wǎng)格提供商不相信 eBPF 是解決所有問題的圣杯。Solo.io 的 Idit Levine 等人針對 Cilium 的這篇公告撰寫了一篇文章 “eBPF for Service Mesh? Yes, But Envoy Proxy is Here to Stay^[8]”。

在 Solo.io，我們認為 eBPF 是優(yōu)化服務網(wǎng)格的很好的方式，并將 Envoy 代理視為數(shù)據(jù)平面的基石。

Solo.io 作者提出的觀點是：邊車代理現(xiàn)在所做的不僅僅是簡單的網(wǎng)絡流量管理。當今的服務網(wǎng)格部署中有著復雜的需求，遠超過 eBPF 支持的有限編程模型，其不符合圖靈完備性且受到內(nèi)核安全的諸多限制。Cilium eBPF 產(chǎn)品可以處理邊車代理許多但并不是全部的任務。此外，Solo.io 的作者還指出，eBPF 的節(jié)點級代理與傳統(tǒng)的 Pod 級邊車代理相比缺乏靈活性，反而增加了整體開銷。eBPF 缺陷在開發(fā)人員必須編寫并部署到服務網(wǎng)格代理中的流量路由、負載均衡和授權的特定應用程序邏輯中體現(xiàn)得尤為明顯。

Terate.io 的開發(fā)人員在回應名為 The Debate in the Community about Istio and Service Mesh^[9] 的 Cilium 公告中也提出了類似的觀點。他們指出，當前邊車代理的性能是合理的，開源社區(qū)也已經(jīng)有了進一步提高性能的方法。與此同時，開發(fā)人員很難在 eBPF 等新穎但圖靈不完整的技術中構建應用程序特定的數(shù)據(jù)平面邏輯。

Istio 架構穩(wěn)定且生產(chǎn)就緒，生態(tài)系統(tǒng)正在發(fā)展期。

eBPF 的許多問題與其是一種內(nèi)核技術分不開，必定收到安全限制。有沒有一種方法可以在不使用空間技術降低性能的情況下將復雜的應用程序特定的代理邏輯集成到數(shù)據(jù)平面中？事實證明，WebAssembly（Wasm）可能會是個選擇。Wasm 運行時可以以近似原生性能安全地隔離和執(zhí)行用戶空間代碼。

Envoy Proxy 率先使用 Wasm 作為擴展機制對數(shù)據(jù)平面的編程。開發(fā)人員可以用 C、C++、Rust、AssemblyScript、Swift 和 TinyGO 等語言編寫應用程序特定的代理邏輯，并將模塊編譯為 Wasm。通過 proxy-Wasm 標準，代理可以在例如 Wasmtime^[10] 和 WasmEdge^[11] 的高性能運行時執(zhí)行這些 Wasm 插件。目前，Envoy 代理^[12]、Istio 代理^[13]、MOSN 和 OpenResty^[14] 支持 proxy-Wasm^[15]。

此外，Wasm 可以充當通用應用程序容器。它在服務網(wǎng)格數(shù)據(jù)平面上的應用不僅限于邊車代理。附加到邊車的微服務也可以運行在輕量級 Wasm 運行時中。WasmEdge WebAssembly 運行時是一個安全、輕量級、快速、便攜式和多語言運行時，Kubernetes 可以直接將其作為容器進行管理^[17]。到 2012 年 12 月，WasmEdge 貢獻者社區(qū)驗證了基于 WasEdge 的微服務可以與 Dapr 和 Linkerd 邊車一同工作，作為帶有 guest 操作系統(tǒng)和完整軟件對戰(zhàn)的重量級 Linux 容器的替代品。與 Linux 容器應用程序相比，WebAssembly 微服務消耗了 1% 的資源，冷啟動時間也只用了 1%。

eBPF 和 Wasm 是服務網(wǎng)格應用的新方向，以便在數(shù)據(jù)平面上實現(xiàn)高性能。他們?nèi)匀皇切屡d技術，但可能會成為微服務生態(tài)系統(tǒng) Linux 容器的替代品或者補充。

關于作者：

Vivian Hu：Vivian 是亞洲的開源愛好者和開發(fā)人員倡導者，Second State 的產(chǎn)品經(jīng)理。她非常關心通過更好的工具、文檔和教程來改善開發(fā)人員體驗和生產(chǎn)力。Vivian 在 WebAssembly.today 上為 WebAssembly、Rust 和無服務器編寫每周時事通訊。

引用鏈接