eBPF 和 Wasm：探索服務網格數據平面的未來

本文翻譯自 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）的數據平面 V2 的一年後，Cilium Service Mesh 帶來了 “無邊車服務網格”（sidecarless service mesh）的想法。它擴展了 Cilium eBPF 產品來處理服務網格中的大部分邊車代理功能，包括 7 層路由和負載均衡、TLS 終止、訪問策略、健康檢查、日誌和跟蹤，以及內置的 Kubernetes Ingress。

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

它將我們從邊車模型中解放處理，並允許我們將現有的代理技術集成到現有的內核命名空間概念中，使其成爲日常使用的優雅容器抽象的一部分。

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

圖片來自 How eBPF will solve Service Mesh - Goodbye Sidecars

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

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

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

並不奇怪，現有的服務網格提供商不相信 eBPF 是解決所有問題的聖盃。Solo.io 的 Idit Levine 等人針對 Cilium 的這篇公告撰寫了一篇文章 “eBPF for Service Mesh? Yes, But Envoy Proxy is Here to Stay[9]”。

在 Solo.io，我們認爲 eBPF 是優化服務網格的很好的方式，並將 Envoy 代理視爲數據平面的基石。

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

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

Istio 架構穩定且生產就緒，生態系統正在發展期。

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

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

容器生態 來自 WasmEdge Book

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

eBPF 和 Wasm 是服務網格應用的新方向，以便在數據平面上實現高性能。他們仍然是新興技術，但可能會成爲微服務生態系統 Linux 容器的替代品或者補充。

關於作者：

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

參考資料

[1] 

《eBPF and Wasm: Exploring the Future of the Service Mesh Data Plane》: https://www.infoq.com/news/2022/01/ebpf-wasm-service-mesh

[2] 

Cilium Service Mesh: https://cilium.io/blog/2021/12/01/cilium-service-mesh-beta

[3] 

How eBPF will solve Service Mesh - Goodbye Sidecars: https://isovalent.com/blog/post/2021-12-08-ebpf-servicemesh

[4] 

Envoy: https://envoyproxy.io/

[5] 

Linkerd: https://linkerd.io/

[6] 

MOSN: https://mosn.io/en/

[7] 

Dapr: https://dapr.io/

[8] 

Infoq 之前報道的那樣: https://www.infoq.com/news/2021/08/linkerd-rust-cloud-native/

[9] 

eBPF for Service Mesh? Yes, But Envoy Proxy is Here to Stay: https://www.solo.io/blog/ebpf-for-service-mesh/

[10] 

Wasmtime: https://github.com/bytecodealliance/wasmtime

[11] 

WasmEdge: https://github.com/WasmEdge/WasmEdge

[12] 

Envoy 代理: https://envoyproxy.io/

[13] 

Istio 代理: https://github.com/istio/proxy

[14] 

OpenResty: http://openresty.org/

[15] 

proxy-Wasm: https://github.com/proxy-wasm

[16] 

將其作爲容器進行管理: https://wasmedge.org/book/en/kubernetes.html

[17] 

Dapr: https://github.com/second-state/dapr-wasm

[18] 

Linkerd: https://github.com/Liquid-Reply/kind-crun-wasm

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/y0D-SPvy2zt-nuVh2xDTzg