Sidecar Pattern
Sidecar pattern — containers running alongside the main application container in a single Kubernetes pod. They share network + volumes but are separate processes. Used for: log shipping (Fluent Bit sidecar), service mesh (Envoy proxy), config reload (watch ConfigMap), secrets sync (Vault agent), data synchronization. Main plus: separation of concerns without application code changes.
Below: details, example, related terms, FAQ.
Details
- Same pod = same IP + shared volumes
- Lifecycle: start/stop together with main container
- Common sidecars: istio-proxy, filebeat, vault-agent, oauth2-proxy
- Init containers: run once before main (setup)
- Downsides: resource overhead × pod_count, complexity
Example
# Pod with sidecar
spec:
containers:
- name: app
image: my-app:v1
- name: log-shipper # sidecar
image: fluent/fluent-bit
volumeMounts:
- { name: logs, mountPath: /var/log }
volumes:
- name: logs
emptyDir: {}Related Terms
Learn more
Frequently Asked Questions
Sidecar vs multi-process container?
Sidecar — separate container (different image + update cycle). Multi-process — all in one image (anti-pattern in K8s, needs supervisord). Sidecar cleaner.
Overhead?
Each sidecar adds: ~30-100 MB memory, CPU slice. In 100-pod cluster — significant. Use only when needed.
Common pitfalls?
Sidecar crash → pod kill if restartPolicy: Always. Use lifecycle hooks + proper readiness probe.