Demystifying Service Mesh (part 2)

In the first part, we delved into the problem that Service Mesh aims to resolve. Now, let's explore the diverse technologies used to construct a Service Mesh and deepen our understanding.

Redirecting/Intercepting Traffic

Whether to use sidecars or not often stirs a discussion. However, both methodologies require that the traffic moving in and out of Kubernetes Pods be intercepted and handled by a proxy. To achieve this, two prevalent methods have emerged:

• Through iptables - A tried and tested method which has been the standard for many years.
• By using eBPF - This is a contemporary, more efficient, and scalable method.

Level 3/4 Processing

Various functions are executed at this level (such as mTLS, level 3/4 authorizations, etc.), and several technologies can come into play:

• Deploying Envoy proxies: Istio, in sidecar mode, employs this method.
• Utilizing an optimized proxy: Istio, in ambient mode, follows this approach. Here, the proxy is built in Rust.
• Using eBPF: This approach is adopted by Cilium, where eBPF can be used to apply level 3/4 authorizations, but it falls short when it comes to providing mTLS. Thus, a userspace program is used alongside eBPF to enable some form of encryption.

Level 7 Processing

Envoy proxy stands as the go-to solution for level 7 processing. Known for its maturity and efficiency, this proxy has been designed to be managed by a control plane via an API. Envoy proxy can handle level 7 authorizations (like permitting only GET HTTP requests), offer advanced routing capabilities, and generate fine-grained telemetry data. It also accommodates many filters and supports the addition of new ones to augment its capabilities (either in C++ or through WebAssembly plugins).

To sum it up, an ideal Service Mesh would combine eBPF for redirecting/intercepting traffic and executing some low-level operations (at level 3/4), an optimized proxy to secure the traffic through mTLS and Envoy to take care of all the level 7 tasks.

The Sidecar or Sidecarless Debate

The question of "sidecar or eBPF?" often arises, but as we've discovered, it's not exactly the right one. The same technologies will be employed whether we opt for sidecars or go sidecarless.

As of now, running a Service Mesh in production requires the use of sidecars. Istio is the most popular choice (and now a graduated CNCF project !), but other mature alternatives also depend on sidecars.

However, the advent of Istio's ambient mesh marks a shift. In this mode, eBPF redirects traffic to a per-node optimized proxy built in Rust, taking over level 3/4 processing. Additionally, a per-identity (a Kubernetes service account) Envoy proxy manages level 7 processing.