Sidecar Proxy

Kubernetes hub

A proxy container automatically injected into every pod in a service mesh. It intercepts all inbound and outbound traffic for the pod, enabling the mesh to apply encryption, retry logic, metrics collection, and routing rules without touching application code.

What is a Sidecar Proxy

The sidecar proxy is the mechanism that makes a service mesh work without application changes. When a pod is created in a mesh-enabled namespace, a second container is automatically injected into it alongside the application container. This second container is the sidecar proxy.

◈ DIAGRAM

Pod (before mesh)          Pod (after mesh injection)
+------------------+       +------------------+
|   Your app       |       |   Your app       |
|   container      |       |   container      |
+------------------+       +------------------+
                           |   Sidecar proxy  |
                           |   (auto-injected)|
                           +------------------+

The sidecar and your app share the same network namespace. The sidecar uses iptables rules to intercept all traffic coming in and going out of the pod - your app never knows the proxy is there.

The Secretary Analogy

Think of the sidecar proxy as a secretary sitting outside every meeting room. Every letter going into the room passes through the secretary first. Every letter going out passes through the secretary too. The people inside the room do not know the secretary is there - they just send and receive as normal.

The secretary:

Logs every letter (metrics and tracing)
Checks credentials before delivery (mTLS)
Can hold back letters if the room is too busy (circuit breaking)
Can route urgent letters to a backup room (failover)

What the Sidecar Proxy Does

◈ DIAGRAM

Inbound traffic:
External request → Sidecar → validates mTLS certificate → App receives request
 
Outbound traffic:
App sends request → Sidecar intercepts → applies retry/timeout/routing → forwards
 
The app opens plain HTTP. The sidecar upgrades to mTLS automatically.
The app receives plain HTTP. The sidecar decrypted the mTLS response.

Proxy Implementations

TEXT

Istio:   Envoy proxy (C++, feature-rich, higher memory usage)
Linkerd: Rust-based micro-proxy (lightweight, lower overhead, fewer features)

Relationship to Control Plane and Data Plane

The sidecar proxy IS the data plane. All sidecars running in your cluster together form the data plane - this is where actual traffic flows. The Control Plane (istiod) pushes configuration to these sidecars and tells them what policies to apply.

Remember
The sidecar proxy intercepts traffic using iptables rules at the pod network namespace level. This happens transparently - no code changes in the application, no special libraries, no SDK required.

Common Mistake
Injecting sidecars into system namespaces like kube-system or istio-system. These system pods were not designed to have their traffic intercepted. Sidecar injection in system namespaces can break DNS, core control plane functions, and other critical cluster components.

Frequently Asked Questions

What exactly does a sidecar proxy do differently from a normal reverse proxy like Nginx?

A sidecar proxy (typically Envoy in Istio, or a Rust-based proxy in Linkerd) runs as a second container inside the same pod, sharing its network namespace, and transparently intercepts every packet in and out of the application container via iptables rules or eBPF — the app doesn't know it's there. A standalone reverse proxy instead sits in front of traffic at a separate network hop and requires the app or infra to explicitly route through it.

What's the main production trade-off engineers underestimate with sidecar proxies?

Every pod now runs two containers instead of one, adding memory and CPU overhead multiplied across your entire fleet, plus an extra network hop's worth of latency per call (usually single-digit milliseconds, but it compounds in deep call chains). It also complicates pod startup/shutdown ordering — if the app container starts before the sidecar is ready, outbound calls fail; Kubernetes 1.29+ native sidecar support (`restartPolicy: Always` on init containers) fixes ordering issues that used to require workarounds.