// Communication & Integration · 10
Sidecar
A buddy container handling logs and config so the app stays clean.
How it fits together
- Orders app uses / calls Log shipper sidecar (localhost)
- Orders app creates Shared volume (1 write logs)
- Log shipper sidecar uses / calls Shared volume (2 read logs)
- Log shipper sidecar publishes / notifies Log backend (3 ship logs)
- Log shipper sidecar uses / calls Config store (read config)
Spot it
- Every service embeds the same infra library
- Services in several languages need one feature
- Upgrading a shared agent means redeploying all
It costs
A container per pod costs memory and adds a hop, and its lifecycle must match the app.
Go deeperThe full explanation and what to ask for · 1 min readExpandCollapse
A sidecar is a helper process deployed next to the application, sharing its lifecycle, network and often a volume. In Kubernetes it is a second container in the same pod, reachable on localhost. Typical jobs: log shipping, proxying, certificate rotation, config reload.
The classic mistake is ignoring startup and shutdown order: the app starts before its proxy is ready, or the sidecar keeps a Job pod running after the main container exits. Kubernetes native sidecars, init containers with restartPolicy Always, start first and stop last.
The pattern lets one implementation serve services written in any language and be upgraded separately from them. A service mesh is a fleet of sidecar proxies under one control plane; application runtimes use the same idea to offer building blocks such as pub/sub and state over HTTP or gRPC.
Ask for it
- pod
- shared network namespace
- localhost
- shared volume
- native sidecar container
- ambassador / adapter
Add a sidecar (Dapr, Envoy, Fluent Bit) to the orders deployment on Kubernetes: the app listens on port 8080, calls inventory through the sidecar on localhost, and reads secrets from the sidecar secret store instead of a cloud SDK.