Sidecar Proxy
A sidecar proxy runs next to each service instance, intercepting network traffic to provide mTLS, retries, routing, and telemetry without application changes.
Definition
A sidecar is a helper process deployed alongside each service instance. In a service mesh, a network proxy sidecar intercepts inbound and outbound traffic, establishes mTLS with peers, applies retries and timeouts, and emits metrics and traces. The application talks to localhost or is transparently redirected by the platform, so the networking policy is uniform across languages.
Context and scope
Sidecars are common in Kubernetes service meshes and for adding capabilities to legacy services that cannot be changed. They trade per-pod resource overhead and operational complexity for consistent networking behavior.
Common misconceptions
- A sidecar is free — it consumes CPU, memory, and connection state per instance
- It replaces application-level retries and deadlines — proxy policy cannot understand every idempotency rule
- It automatically makes a service secure — it encrypts transport and can enforce network policy, but not user authorization
Anti-patterns
- Injecting a sidecar into every pod before the team can operate it
- Letting the sidecar retry non-idempotent requests without the application's consent
- Ignoring sidecar startup ordering and shutdown draining
Related concepts
Authoritative source
A proxy per instance
The sidecar runs in the same pod or host namespace as the application. The platform redirects traffic through it. The proxy can authenticate both ends with mTLS, apply a retry budget, route by version, and report latency without the application importing a networking library.
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders
spec:
template:
metadata:
annotations:
sidecar.istio.io/inject: "true"The example shows opt-in injection. The important operational details are less visible: the proxy must be ready before the app receives traffic, and it must drain connections before the app exits.
Lifecycle and resources
A sidecar adds a container to every pod. It consumes memory and CPU proportional to connections and traffic, and it can fail independently. Set resource requests and limits, include the proxy in readiness checks, and ensure shutdown order: stop accepting new traffic, drain the proxy, then terminate the application. A sidecar that outlives the app can hold listeners and confuse the next rollout.
Keep policy understandable
A mesh can express retries, timeouts, circuit breaking, and routing. Applying all of them at the proxy without understanding the application’s idempotency and deadlines can make failures worse. Treat proxy policy as production configuration: review it, test it, and document which layer owns which behavior.
When to use it
Use a sidecar when uniform transport security and telemetry across many services justify per-instance overhead, or when a legacy service cannot be changed. The advantage is consistency without code changes; the drawback is resource cost, lifecycle complexity, and another layer in every request. Compared to an API gateway, a sidecar covers east-west traffic and per-instance policy rather than a shared north-south entry point.