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）以提供网络代理以外的应用程序服务。此类服务的示例还包含了服务注册、服务发现、资源绑定、基于名称的服务调用、状态管理、actor 框架 和密钥存储。
边车代理通常在 Kubernetes Pod 或者容器中运行。微服务应用也同样运行在容器内，并通过网络接口连接到边车。然而，这些容器化应用程序的一个重要问题就是资源消耗。边车服务随着微服务的数量几何级增长。当应用程序有数百个互联和负载均衡的微服务时，开销变得难以接受。服务网格代理商开始了性能上的竞争。正如 Infoq 之前报道的那样[7]，Linkerd 将其 Go 写的代理用 Rust 重写了，并获得了显着的性能提升。
并不奇怪，现有的服务网格提供商不相信 eBPF 是解决所有问题的圣杯。Solo.io 的 Idit Levine 等人针对 Cilium 的这篇公告撰写了一篇文章 “eBPF for Service Mesh? Yes, But Envoy Proxy is Here to Stay[8]”。
在 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[9] 的 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[16]
此外，Wasm 可以充当通用应用程序容器。它在服务网格数据平面上的应用不仅限于边车代理。附加到边车的微服务也可以运行在轻量级 Wasm 运行时中。WasmEdge WebAssembly 运行时是一个安全、轻量级、快速、便携式和多语言运行时，Kubernetes 可以直接将其作为容器进行管理[17]。到 2012 年 12 月，WasmEdge 贡献者社区验证了基于 WasEdge 的微服务可以与 Dapr 和 Linkerd 边车一同工作，作为带有 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]
Infoq 之前报道的那样: https://www.infoq.com/news/2021/08/linkerd-rust-cloud-native/
[8]
eBPF for Service Mesh? Yes, But Envoy Proxy is Here to Stay: https://www.solo.io/blog/ebpf-for-service-mesh/
[9]
The Debate in the Community about Istio and Service Mesh: https://www.tetrate.io/blog/the-debate-in-the-community-about-istio-and-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]
WasmEdge Book: https://wasmedge.org/book/en/kubernetes.html
[17]
将其作为容器进行管理: https://wasmedge.org/book/en/kubernetes.html