eBPF与Wasm：探索服务网格数据平面的未来

by

• Vivian Hu

摘要：

随着eBPF和WebAssembly（WASM）等轻量级运行时的发展，我们现在看到了新一代的服务网状数据平面解决方案，它们更轻便、更安全、更快速。

2021年12月2日，Cilium项目宣布了Cilium服务网格的beta测试计划。在谷歌云基于eBPF的谷歌Kubernetes服务（GKS）Dataplane V2（于2020年8月发布）所开创的概念基础上，Cilium服务网格倡导“无sidecar服务网格”的理念。它扩展了Cilium eBPF产品，以处理服务网格中大部分sidecar代理的功能，包括L7路由和负载均衡、TLS终止、访问策略、健康检查、日志与跟踪，以及内置的Kubernetes ingress。

Cillium的创建者Isovalent在一篇题为“eBPF将如何解决服务网格的问题--再见Sidecar”的文章中阐述了使用eBPF代替sidecar代理的理由。

它能够将我们从sidecar模型中解放出来，允许我们将现有的代理技术集成到现有的内核命名空间概念中，从而使它们成为我们每天都在使用的容器抽象的一部分。

简而言之，eBPF承诺会解决服务网格中的一个主要痛点，那就是当存在数量众多的微服务时，会导致较差的性能。但是，使用eBPF来取代sidecar是一个新的想法，并非没有争议。

（来源：eBPF将如何解决服务网格的问题--再见Sidecar）

在服务网格中，数据平面指的是基础设施服务，它会管理数据流量如何路由和投递给微服务应用。目前，这主要是通过使用服务代理实现的。这种设计模式通常被称为sidecar模式。sidecar能够允许其关联的微服务以透明的方式向服务网格中的其他组件发送和接收请求。

sidecar一般会包含一个L7的网络代理，比如Envoy、Linkerd或MOSN。代理要处理流量路由、负载平衡、健康检查、认证、授权、加密、日志、跟踪和统计数据收集。sidecar还可以包含一个基于SDK的应用框架，比如Dapr，以提供网络代理之外的应用服务。举例来讲，这种应用服务包括服务注册、服务发现、资源绑定、基于名字的服务调用、状态管理、actor框架和secret存储。

sidecar代理和服务通常会在Kubernetes pod或容器中运行。微服务应用也会在容器中运行，它们通过网络接口关联到sidecar上。但是，这种容器化应用的方式有一个明显的问题那就是资源的消耗。sidecar服务会随着微服务的数量呈几何级数增加。当一个应用有数百个相关连接和负载均衡的微服务时，所带来的开销就会变得难以承受。服务网格代理供应商在性能方面展开了竞争。正如InfoQ最近所报道的，Linkerd使用Rust重写了原本基于Go实现的代理，并取得了明显的性能提升。

不出意料的是，现有的服务网格供应商并不相信eBPF会是解决我们所有问题的灵丹妙药。来自Solo.io（一个基于Envoy Proxy和Istio的领先的服务网格供应商）的Idit Levine等人撰写了一篇文章来回应Cilium的公告。该文章的标题就是“用于服务网格的eBPF？是的，但Envoy代理将会继续存在”。

在Solo.io，我们认为eBPF是一个优化服务网格的强大方式，同时，我们也认为Envoy代理是数据平面的基石。

Solo.io作者提出的关键点是，sidecar代理现在的作用远远超过了简单的网络流量管理。如今的服务网格部署有复杂的要求，远远超过了eBPF所支持的有限的编程模型，eBPF是图灵不完备的，对内核的安全有许多限制。Cilium eBPF的产品可以解决许多sidecar代理所能处理的各种任务，但不是全部。此外，Solo.io的作者指出，eBPF的每个节点一个代理（one-proxy-per-node）的设置提供了更少的灵活性，因此与传统代理的每个pod一个代理（one-proxy-per-pod）的设置相比，会增加整体的开销。如果开发者必须编写应用程序特定的流量路由、负载平衡和授权等逻辑并将其部署到服务网格中的话，那么eBPF的这些缺点会更加明显。

Terate.io的开发人员在对Cilium公告的回应中提出了类似的论点，他们撰写了一篇名为“社区中关于Istio和服务网格的争论”的博客文章。他们指出，如今的sidecar代理的性能是合理的，开源社区已经想出了进一步提高性能的方法。同时，对于开发者来说，在eBPF这样一个新颖的、图灵不完备的技术中构建应用程序特定的数据平面逻辑是非常困难的。

Istio架构是稳定的，可以投入生产的，而且生态系统正在蓬勃发展。

eBPF的很多问题都与它是一种内核技术有关，因此必须要有安全限制。有没有一种方法可以在不使用使用用户空间技术（这会导致性能下降）的情况下，将复杂的应用程序特定的代理逻辑纳入数据平面中？事实证明，WebAssembly（Wasm）可能是一个选项。Wasm运行时可以安全地隔离并以接近原生的性能执行用户空间代码。

Envoy Proxy开创了一种方式，支持使用Wasm作为扩展机制实现数据平面编程。开发人员可以用C、C++、Rust、AssemblyScript、Swift和TinyGo等语言编写应用程序特定的代理逻辑，并将模块编译到Wasm中。通过proxy-Wasm标准，代理可以在高性能运行时（如Wasmtime和WasmEdge）中执行这些Wasm插件。目前，Envoy Proxy、Istio Proxy、MOSN和OpenResty都支持proxy-Wasm。

（容器生态系统中的Wasm。来源：WasmEdge Book）

此外，Wasm可以作为一个通用的应用容器。在服务网格的数据平面方面，它的应用并不局限于sidecar代理。关联到sidecar的微服务可以在它自己的轻量级Wasm运行时中运行。WasmEdge WebAssembly运行时是一个安全、轻量级、快速、可移植和支持多语言的运行时，可以直接由Kubernetes作为容器管理。截止2021年12月，WasmEdge社区的贡献者证明了基于WasmEdge的微服务可以与Dapr和Linkerd的sidecar一起工作，能够替代重量级的完整Linux容器，而这种完整的容器通常都需要guest OS和完备的软件栈。与Linux容器应用相比，WebAssembly微服务仅消耗1%的资源，冷启动时间为1%。

eBPF和Wasm是服务网格应用在数据平面上实现高性能的新生力量。它们仍然是新生的技术，但有可能成为今天微服务生态系统中Linux容器的替代品或补充。

关于作者

Vivian Hu

Vivian是来自亚洲的一个开源爱好者和开发者倡导者。她是Second State的产品经理。她非常关注如何通过更好的工具、文档和教程来改善开发者的体验和生产力。Vivian在WebAssembly.today上为WebAssembly、Rust和无服务器技术撰写了一份每周新闻通讯。

查看英文原文：eBPF and Wasm: Exploring the Future of the Service Mesh Data Plane