TOPIC CONTAINERS
Sidecar Pattern attaching helper containers to your pod without modifying app code
IN 10 SECONDS
A sidecar is an additional container running in the same pod as your main application container. They share the same network namespace and volume mounts. Common use cases: logging agents (Fluentd), service mesh proxies (Envoy), secret reloaders, and metrics exporters. The app stays blissfully unaware of the sidecar.
GOTCHA A failed sidecar restarts independently from the app — unless you use a startup/readiness probe that ties the pod's health to the sidecar. Without it, a dead sidecar means the pod looks healthy but features (logging, mTLS) are silently broken.
HOW A SIDECAR OPERATES
01 Pod startup Kubernetes starts both the main app container and the sidecar container simultaneously.
02 Shared network both containers share the same IP and localhost — the sidecar can intercept or observe traffic.
03 Shared volume the sidecar mounts the same emptyDir volume as the app to read/write logs or config files.
04 Sidecar job the sidecar tails log files and ships them to stdout or an external aggregator (CloudWatch, Loki).
POKE IT YOURSELF
kubectl logs deployment/my-app -c sidecar-proxy — view logs of just the sidecar container
kubectl exec deployment/my-app -c sidecar-proxy -- ls /var/log — exec into the sidecar
Drill this topic →
~75 sec read