BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News eBPF and Wasm: Exploring the Future of the Service Mesh Data Plane

eBPF and Wasm: Exploring the Future of the Service Mesh Data Plane

This item in japanese

Bookmarks

On Dec 2nd, 2021, the Cilium project announced a beta testing program for Cilium Service Mesh. Building on the concept pioneered by Google Cloud’s eBPF-based Google Kubernetes Service (GKS) Dataplane V2, announced a year earlier in August 2020, Cilium Service Mesh promotes the idea of "sidecarless service mesh". It expands the Cilium eBPF product to handle much of the sidecar proxy functionalities in a service mesh, including L7 routing and load balancing, TLS termination, access policies, health checks, logging and tracing, and build-in Kubernetes ingress.

Isovalent, the creator of Cillium, explained the rationale behind using eBPF as an alternative to sidecar proxy in an article titled "How eBPF will solve Service Mesh - Goodbye Sidecars".

It will free us from the sidecar model and allows us to integrate existing proxy technology into existing kernel namespacing concepts allowing them to become part of the beautiful container abstraction we already use every day.

In a nutshell, eBPF promises to solve a major pain point in service mesh — the lack of performance when there are many finely grained microservices. However, using eBPF to replace the sidecar proxy is a novel idea and is not without controversies.

service mesh evolution

(source: How eBPF will solve Service Mesh - Goodbye Sidecars)

The data plane in a service mesh refers to infrastructure services that manage how data traffic is routed and delivered to and from microservice applications. Currently, this is achieved via the use of service proxies. This design pattern is also commonly known as the sidecar pattern. A sidecar allows its attached microservices to make and receive requests transparently to and from other components in the service mesh.

The sidecar typically contains an L7 network proxy, such as Envoy, Linkerd, or MOSN. The proxy handles traffic routing, load balancing, health checking, authentication, authorization, encryption, logging, tracing, and statistics collection. The sidecar could also contain an SDK-based application framework, such as Dapr, to provide application services beyond network proxy. Examples of such application services include service registration, service discovery, resource binding, name-based service invocation, state management, actor framework, and secrets store.

The sidecar proxy and services typically run inside Kubernetes pods or containers. The microservice applications also run inside containers, and they attach to sidecars via network interfaces. However, a significant issue with those containerized applications is resource consumption. The sidecar services increase geometrically with the number of microservices. When an application has hundreds of interlinked and load-balanced microservices, the overhead could become overwhelming. Service mesh proxy vendors compete on performance. As InfoQ reported previously, Linkerd rewrote its proxy from Go to Rust and achieved notable performance gains.

Unsurprisingly, existing service mesh providers do not believe that eBPF is the holy grail that will solve all our problems. Idit Levine et al. from Solo.io, a leading service mesh provider based on Envoy Proxy and Istio, wrote an article in response to the Cilium announcement. The article is titled "eBPF for Service Mesh? Yes, But Envoy Proxy is Here to Stay."

At Solo.io, we see eBPF as a powerful way to optimize the service mesh, and we see Envoy proxy as the cornerstone of the data plane.

The key point the Solo.io authors made is that the sidecar proxy now does much more than simple network traffic management. There are complex requirements in today’s service mesh deployments that far exceed the limited programming models supported by eBPF, which is Turing-incomplete and has numerous restrictions for the safety of the kernel. The Cilium eBPF product can handle many, but not all, of the diverse tasks performed by the sidecar proxy. Furthermore, the Solo.io authors noted that eBPF’s one-proxy-per-node setup offers much less flexibility and hence increases the overall overhead compared against traditional proxy’s one-proxy-per-pod setup. These eBPF shortcomings are especially pronounced for application-specific logic for traffic routing, load balancing, and authorization that developers must write and deploy into the service mesh proxy.

Developers at Terate.io made similar arguments in their response to the Cilium announcement titled "The Debate in the Community about Istio and Service Mesh". They noted that the performance of today’s sidecar proxy is reasonable and the open-source community has already figured out ways to further enhance the performance. At the same time, it is very difficult for developers to build application-specific data plane logic in a novel and Turing-incomplete technology like the eBPF.

The Istio architecture is stable and production-ready, and the ecosystem is budding.

Many of eBPF’s issues are related to the fact that it is a kernel technology, and hence must have safety restrictions. Is there a way to incorporate complex application-specific proxy logic into the data plane without degrading performance using use space technologies? It turns out that WebAssembly (Wasm) might just be that choice. The Wasm runtime can securely isolate and execute userspace code in near-native performance.

Envoy Proxy pioneered the approach to use Wasm as an extension mechanism to program the data plane. Developers can write application-specific proxy logic in languages like C, C++, Rust, AssemblyScript, Swift, and TinyGo, and compile the module into Wasm. Through the proxy-Wasm standard, the proxy can execute those Wasm plug-ins in high-performance runtimes such as Wasmtime and WasmEdge. Currently, Envoy Proxy, Istio Proxy, MOSN, and OpenResty support proxy-Wasm.

kubernetes.png

(Wasm in the container ecosystem. Source: WasmEdge Book)

Furthermore, Wasm could act as a general-purpose application container. Its application on the service mesh data plane is not limited to the sidecar proxy. The microservice attached to the sidecar could run in its own lightweight Wasm runtime. The WasmEdge WebAssembly Runtime is a secure, lightweight, fast, portable, and polyglot runtime that can be directly managed by Kubernetes as containers. By Dec 2021, the WasmEdge community of contributors demonstrated that WasmEdge-based microservices can work with Dapr and Linkerd sidecars as an alternative to heavyweight full-blown Linux containers with guest OS and full software stacks. The WebAssembly microservices consume 1% of resources, and cold starts in 1% of the time compared with Linux container applications.

eBPF and Wasm are the new kids on the block for service mesh applications to achieve high performance in the data plane. They are still nascent technologies, but could potentially become alternatives or supplements to today’s Linux containers in the microservice ecosystem.

About the Author

Rate this Article

Adoption
Style

BT