A proxy in the same pod
A sidecar proxy runs in the same deployment unit as the application, such as the same pod, sharing its network namespace. The application sends and receives traffic as usual, but iptables rules quietly redirect that traffic through the sidecar first.
This is what makes a mesh transparent: the application code does not import a mesh library. It still calls a normal address, and the sidecar intercepts the connection.
What the sidecar handles
- Outbound calls leave the app, hit the local sidecar, and are encrypted and load balanced before going to the destination sidecar.
- Inbound calls arrive at the sidecar, are decrypted and checked, then handed to the app over the loopback.
Cost and benefit
The benefit is uniform networking behavior across every language without code changes. The cost is an extra process and an extra network hop per call, adding latency and memory. Teams accept this for the operational consistency, though it is why some newer designs explore moving the proxy into the host kernel or a shared node level agent.
Key idea
A sidecar proxy runs beside each service and transparently intercepts its traffic so mesh features apply without changing application code.