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
Coming Soon!