The Sidecar Proxy Model (Istio & Envoy)

The Motorcycle and the Sidecar

The most common way service meshes work today — used by projects like Istio and Linkerd — is the Sidecar Pattern.

Think of your application container as a motorcycle. It is excellent at driving (executing business logic), but it has no built-in GPS, no security checkpoint, and no black box recorder. A service mesh attaches a "sidecar" — a small, separate container — to your motorcycle. The sidecar handles navigation, security, and logging so the motorcycle can focus entirely on driving.

In Kubernetes terms, this sidecar is a proxy container (almost always Envoy) injected into the same Pod as your application. Because containers in the same Pod share a network namespace, the sidecar can intercept all traffic going in and out of the application.

The traffic flow, step by step:

1. Your application calls http://payment-service/charge. It thinks it is talking directly to the network.
2. iptables rules — installed automatically by the mesh agent on the host node — intercept that outbound packet and redirect it to the local Envoy sidecar on a loopback port (typically 15001).
3. Envoy applies routing rules, adds retry logic, encrypts the traffic with mTLS, and forwards it to the destination node.
4. On the receiving pod, the destination's Envoy sidecar intercepts the inbound packet, decrypts it, verifies the caller's identity, and only then hands the request to the application.
5. The application receives the request as if it came directly from the network. It has no idea the sidecar exists.

This transparency is intentional. Applications require zero code changes to gain mesh features.

The sidecar model does have a real cost: every pod runs an extra container. In a cluster with 2,000 pods, that is 2,000 Envoy processes consuming memory and CPU. At scale, this overhead becomes a meaningful operational concern — which is why alternative approaches exist (covered in the eBPF section below).