Introduction
If you’ve ever used Istio Service Mesh or Cilium Service Mesh, you’ve likely seen what feels like “magic”: you deploy an app, add an annotation, and suddenly traffic between services is encrypted, L7 observability appears, and fine-grained network policies can be enforced — all without changing a single line of application code.
But how is this possible?
Kubernetes services believe they are communicating directly with other services, but in reality, their traffic is transparently intercepted and processed by an intermediary that applies policy, observability, and encryption - without any changes to the application code. This pattern is called a Service Mesh.
In this skill path, you’ll go from a minimal setup that intercepts and transparently proxies client requests on both the client and server side using eBPF and Envoy to extending it with features such as SO_ORIGINAL_DST and eBPF socket acceleration.
Happy 🐝-ing!
Transparent Egress Proxy with eBPF and Envoy
Loading tutorial...
When you start learning how a Service Mesh works, one of the most fundamental concepts to understand is transparent traffic redirection. Put simply, how can we place a proxy like Envoy in the network path between two services without requiring any changes on either side—or even making the services aware that the proxy exists?
In this lab, we focus on transparent proxying on the sending Pod—that is, the client side. You'll learn how eBPF can be used to make the client think as if nothing exists in the network path, even though the traffic is being transparently intercepted by Envoy.
Transparent Ingress Proxy with eBPF and Envoy
Loading tutorial...
So far we looked at how to transparently redirect egress traffic, where the requests are intercepted on the client side and proxied through Envoy. But if we really want to build a minimal service mesh, the interception also need to occur on the server side.
It might seem weird, that we actually intercept the traffic twice along the network path between services, but that's actually necessary for the service mesh.
Client-side interception, on the other hand, allows the mesh to apply policies before the request leaves the workload—such as enforcing network policies, mTLS, and collecting L7 metrics.
Server-side interception ensures that incoming traffic is authenticated, authorized, and observable in a consistent way, regardless of how the client is implemented.
In this lab, we focus on transparent proxying on the receiving Pod—that is, the server side. You'll learn how eBPF can be used to make the server think as if nothing exists in the network path, even though the traffic is being transparently intercepted by Envoy.