The sidecar pattern deploys a secondary, helper component alongside a primary application so that the helper can extend the application’s capabilities without modifying its code. The name evokes a motorcycle sidecar: an attachment that travels with the main vehicle and shares its journey. In modern infrastructure the helper is usually a separate container that runs next to the service it supports.
The Kubernetes documentation gives a precise statement of the idea. It defines sidecar containers as “the secondary containers that run along with the main application container within the same Pod,” used “to enhance or to extend the functionality of the primary app container by providing additional services, or functionality such as logging, monitoring, security, or data synchronization, without directly altering the primary application code.” Because both containers share the same Pod, they share a network namespace and can share storage, which lets the sidecar intercept the application’s traffic or read its files with minimal friction.
A key property is independent lifecycle. The sidecar can be started, stopped, updated, and scaled separately from the main application, and the two are developed and reasoned about as distinct units. Kubernetes formalized native sidecar support by implementing sidecars as init containers with a restartPolicy of Always, which gives them well-defined startup ordering and lenient termination behavior relative to ordinary containers.
The pattern is the foundation of the service mesh. A mesh such as Istio injects a proxy, typically Envoy, as a sidecar next to each service instance and routes all of the service’s inbound and outbound traffic through that proxy. The application sends and receives ordinary network calls; the sidecar transparently adds mutual TLS, retries, load balancing, and telemetry. This is how a mesh delivers networking capabilities “without code changes.”
The sidecar’s appeal is separation of concerns: cross-cutting infrastructure logic lives in a reusable companion process rather than being copied into every application. Its cost is overhead, since running a proxy beside every workload consumes memory and CPU and adds operational complexity. That trade-off is exactly what newer proxyless and per-node approaches, such as Istio’s Ambient mode, were designed to reduce.