Sidecar

Overview

A sidecar is a companion process attached to a primary application, like a sidecar on a motorcycle. It extends the application without modifying it and lives and dies with it.

How it works

In Kubernetes, containers in one pod share a network namespace and can share volumes. A proxy sidecar intercepts or receives traffic on localhost, applies policy and forwards it.

Pod
+------------------------------+
| app  <--localhost-->  sidecar|--> network
|   \--shared volume--/        |
+------------------------------+

Common roles: mesh proxy for mTLS and retries, log forwarder tailing a shared volume, secret refresher writing credentials to a file, config watcher reloading settings.

Pitfalls

• Startup ordering. Make the app wait for sidecar readiness or use native sidecar container support so ordering is guaranteed.
• Shutdown ordering. Traffic proxy must outlive the app while it drains in-flight requests.
• Jobs that never finish because the sidecar keeps the pod running.
• Under-sized resource requests, causing throttling of the proxy and tail latency spikes.
• Multiplying overhead: fifty instances at 100 MB each is 5 GB just for helpers.
• Version skew across the fleet after slow sidecar upgrades.

Key takeaways

• Sidecars move cross-cutting concerns out of application code.
• They share lifecycle, network and storage with the app.
• Budget the per-instance cost and manage version rollouts.
• Define explicit startup and shutdown ordering.
• Prefer a library when you have one language and tight latency needs.