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

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

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

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

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

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

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

并不奇怪，現(xiàn)有的服務(wù)網(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ù)網(wǎng)格的很好的方式，并將 Envoy 代理視為數(shù)據(jù)平面的基石。

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

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

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

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

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

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

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

關(guān)于作者：

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

引用鏈接