The Architecture of the Sidecar Pattern

What the sidecar pattern actually is

A sidecar is a helper process that runs alongside your main application, packaged as a separate container in the same deployment unit — in Kubernetes, the same Pod. (A common misconception is that the app and sidecar share one container; they do not. They are distinct containers that happen to share a Pod.) Because they live in the same Pod, they share a network namespace, can talk over loopback, and are scheduled, started, and torn down as a unit.

The point of the pattern is to move cross-cutting concerns — mutual TLS, retries, timeouts, circuit breaking, load balancing, rate limiting, metrics, and tracing — out of the application process and into the sidecar. The app keeps doing its one job (serve orders, process payments) and stays blissfully unaware that a proxy is intercepting every byte on and off the wire. This is exactly how a service mesh such as Istio works: it injects an Envoy proxy sidecar next to each workload.

Three architectural properties that define it

1. Co-location. App and sidecar share the Pod, so they share an IP address and a loopback interface. The sidecar can reach the app at 127.0.0.1 without leaving the Pod, and vice versa.
2. Shared lifecycle. They are created and destroyed together. The sidecar is guaranteed to be present for as long as the app is running — which is what makes it safe to route all of the app's traffic through it.
3. Transparent network interception. The sidecar sits in the data path for every inbound and outbound connection, acting as a proxy — without the application being reconfigured. This is the property people gloss over, and it is the one that requires the most care to get right, because it is implemented with kernel packet redirection, not application cooperation.

How the interception actually works (the load-bearing detail)

The app is never told to talk to the sidecar. Instead, an init step programs iptables rules inside the Pod's network namespace that hijack the app's connections. There are two directions, and they use two different Envoy listeners on two well-known ports:

• 15001 — virtualOutbound: where the app's outbound connections get redirected.
• 15006 — virtualInbound: where inbound connections get redirected before reaching the app.

Both are Pod-local addresses — they live on 127.0.0.1 and never appear on the network. This is the single most important thing to internalize: ports 15001 and 15006 do not travel on the wire. A packet only lands on 15006 because the destination Pod's iptables PREROUTING chain (ISTIO_IN_REDIRECT) transparently redirects traffic that arrived for the app's real port. What crosses the network between two Pods is the destination Pod's IP and the application's real port — for example 10.1.2.7:8080.

A request, traced end to end

Scenario: the orders service (Pod 10.1.1.4) calls the payments service. The chosen payments Pod is 10.1.2.7, and its app listens on 8080.

1. The orders app opens a plain TCP connection to payments:8080. It knows nothing about Envoy.
2. In the orders Pod's network namespace, iptables OUTPUT (chain ISTIO_OUTPUT) transparently redirects that outbound connection to the local sidecar's virtualOutbound listener at 127.0.0.1:15001.
3. The outbound Envoy matches the request to the payments cluster and, via EDS (endpoint discovery), selects a concrete upstream endpoint: the payments Pod at 10.1.2.7:8080 — the application's real port. It begins an mTLS handshake and connects, using ORIGINAL_DST, to that endpoint address.
4. On the wire, the packets leaving the orders Pod are mTLS-encrypted TCP whose destination is 10.1.2.7:8080 — the destination Pod's IP and the app's real port. The value 15006 does not appear anywhere on the network.
5. The packets arrive in the payments Pod's network namespace, still addressed to 10.1.2.7:8080. There, iptables PREROUTING (chain ISTIO_INBOUND → ISTIO_IN_REDIRECT) transparently redirects inbound traffic bound for the app's ports to 127.0.0.1:15006, the virtualInbound listener. This redirect is what puts the connection on 15006 — nothing was addressed to 15006 before this hop.
6. virtualInbound (15006) terminates mTLS, verifies the peer's SPIFFE identity, and applies inbound authorization and telemetry.
7. The inbound Envoy forwards the now-plaintext request to the payments app over loopback at 127.0.0.1:8080. The app receives an ordinary local connection, unaware a proxy was ever in the path.

Sanity check on the two easy-to-confuse hops: the endpoint Envoy dials (step 3) and the wire destination (step 4) are both 10.1.2.7:8080; 127.0.0.1:15006 is a Pod-local artifact created by the iptables redirect in step 5, not a destination anyone routes to.

Injection and lifecycle: native sidecar containers

The sidecar can be added at deploy time (a mutating admission webhook rewrites the Pod spec to add the Envoy container and an init step that installs the iptables rules). But how the sidecar container is declared matters for lifecycle correctness.

Ordinary sidecars — declared in the Pod's normal containers list — have two long-standing problems: there is no ordering guarantee, so the app can start (or the sidecar can shut down) before the proxy is ready; and in a Job the Pod never completes, because the sidecar keeps running after the app's work is done.

Kubernetes addressed this with native sidecar containers: a container declared in initContainers with restartPolicy: Always. Such a container starts before the app containers, stays running for the Pod's lifetime, and does not block Job completion. Precise version history: the underlying SidecarContainers feature gate was alpha and disabled by default in Kubernetes v1.28, then promoted to beta and enabled by default in v1.29. So while the mechanism first appeared in 1.28, you should not rely on it being on by default until 1.29.

When to reach for it — and when not to

The sidecar is a tool with a real cost, so the judgment is about selection against alternatives, not just mechanics.

Use a sidecar when

• You need uniform cross-cutting behavior (mTLS, retries, traffic policy, tracing) across many services in different languages, and you don't want to reimplement it per language.
• You want to upgrade the capability independently of the app — patch a TLS/CVE issue by rolling the proxy, not every service.
• You're adopting a service mesh and want per-workload policy and identity.

Prefer an alternative when

• In-process libraries (gRPC's built-ins, Resilience4j, Polly): lowest latency and no extra container, but must be built/versioned per language and redeployed with the app. Best for a small, homogeneous fleet.
• Node-level / host agent (DaemonSet): one proxy per node instead of per Pod — far less overhead at scale, but weaker isolation and a larger blast radius per instance.
• Sidecar-less / ambient mesh (e.g. Istio ambient with a per-node ztunnel plus optional waypoint proxies): keeps mesh identity and mTLS while removing the per-Pod proxy tax — attractive when the sidecar resource multiplication hurts.

Avoid it when

• Latency-critical hot paths: every call now traverses two extra proxy hops plus TLS work.
• Resource-constrained or very large fleets: each Pod carries its own proxy, so CPU/memory cost scales with Pod count (N Pods = N proxies).
• Simple systems where a single library dependency already solves the problem.

Net trade-off: you buy language-agnostic, independently-upgradable, uniformly-enforced networking and security, and you pay for it in per-Pod resource overhead, added latency, and operational complexity.

Sources

• Brendan Burns and David Oppenheimer, Design Patterns for Container-based Distributed Systems, USENIX HotCloud 2016 — the original articulation of the sidecar, ambassador, and adapter patterns.
• Istio documentation — Architecture and Traffic Management, and the sidecar traffic-capture / iptables redirection details (istio-iptables, ports 15001 virtualOutbound and 15006 virtualInbound). https://istio.io/latest/docs/ops/deployment/architecture/
• Envoy proxy documentation — Original destination (ORIGINAL_DST) listener/cluster and endpoint discovery (EDS). https://www.envoyproxy.io/docs/
• Kubernetes documentation — Sidecar Containers (native sidecars via initContainers with restartPolicy: Always); SidecarContainers feature gate: alpha in v1.28, beta/on-by-default in v1.29. https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/