Sidecar
A helper container running alongside the main app container in the same pod, handling cross-cutting concerns (proxying, logging, metrics). Decouples operational concerns from app code. The basis of service meshes.
- Service meshes and uniform operational features.
- Polyglot orgs needing consistent observability/security.
- Small clusters where the overhead isn't justified.
- When you can use node-level Daemons instead.
Definition
A sidecar is a co-located container sharing the pod's network and storage with the main container. It implements concerns like mTLS, retries, metrics, or log forwarding, so the app stays focused on business logic.
Why it exists
Every service needs the same operational features (mTLS, tracing, retries). Building them into each app is duplicative and language-specific. A sidecar centralizes them, language-agnostically, per pod.
How it works
Deployed in the same pod as the app, sharing localhost and volumes. The sidecar intercepts traffic (as a proxy) or reads logs/metrics. The control plane configures all sidecars uniformly. Adds CPU/memory overhead per pod.
Scaling limits
Resource overhead per pod (memory/CPU for the sidecar). Adds a network hop (in-pod). Upgrading sidecars means rolling all pods. Misconfigured sidecars affect every app.
Cost shape
Per-pod overhead (small but adds up at thousands of pods). Blow-ups: sidecar memory and the operational cost of upgrades.
Alternatives
- Node-level daemon — Less overhead, but less per-app control.
- In-app library — No overhead, but language-specific and duplicative.
Failure modes
- Sidecar bugs affecting all apps.
- Upgrade complexity.
- Resource contention with the app.