A sidecar is a secondary container that runs next to the main application container in the same unit, such as a Kubernetes pod. Because they share the network namespace and can share volumes, the sidecar can support the application without changing its code.
Why it matters
The sidecar pattern separates cross-cutting concerns from business logic. Common uses are shipping logs, refreshing secrets or certificates, running a local proxy that handles TLS and retries (as in a service mesh), and syncing configuration files. The application stays small, and the helper can be updated or reused across many applications written in different languages.
The cost is extra resource use per pod and one more component whose failure or slow start can affect the application.
Example
spec:
containers:
- name: app
image: example/app:2.1
- name: log-shipper
image: example/log-agent:1.4
volumeMounts:
- name: logs
mountPath: /var/log/app
volumes:
- name: logs
emptyDir: {}The app writes log files to the shared volume and the sidecar forwards them elsewhere.
Common mistakes
- Giving the sidecar no resource limits, so it starves the main container.
- Ignoring start order, so the app begins before its proxy is ready.
- Using a sidecar when a node-level agent would serve every pod more cheaply.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.