Sidecar Container
Kubernetes co-located helper container pattern
A sidecar container is a secondary container deployed alongside a main application container within the same pod, providing supporting functionality such as logging, proxying, or security without modifying the main application's code.
Definition
A sidecar container is a secondary container deployed alongside a main application container within the same pod, providing supporting functionality such as logging, proxying, or security without modifying the main application's code.
Overview
The sidecar pattern takes its name from a motorcycle sidecar: a secondary unit attached to and traveling alongside the primary vehicle, sharing its journey but serving a distinct purpose. In Kubernetes, a sidecar container runs in the same pod as an application's main container, sharing the pod's network namespace and, optionally, its storage volumes, while remaining a separately deployed and versioned piece of software. This pattern is popular because it lets teams add cross-cutting functionality — logging aggregation, metrics collection, TLS termination, configuration reloading, or network proxying — without modifying or even recompiling the main application. The service mesh model, popularized by tools like Istio and Linkerd, relies heavily on sidecars: an Envoy proxy sidecar is injected into every pod to transparently intercept and manage network traffic, implementing retries, load balancing, and mutual TLS across an entire fleet of services without any application code changes. Because a sidecar shares the pod's lifecycle, it starts and stops together with the main container (with the exception of native Kubernetes sidecar containers, a feature added to formalize startup and shutdown ordering), and it shares the same resource quota and network address as the container it supports. This tight coupling is both the pattern's strength — deployment and scaling stay simple, since the sidecar always travels with its application — and its main cost, since every pod running a sidecar pays its resource overhead. Common sidecar use cases include log shippers like Fluent Bit, service mesh proxies like Envoy, and secrets-fetching agents like Vault Agent, each attaching specialized behavior to an application pod without touching that application's own code.
Key Concepts
- Runs alongside the main application container in the same pod
- Shares the pod's network namespace and optionally its storage volumes
- Adds cross-cutting functionality without modifying application code
- Foundational to the service mesh pattern via proxy sidecars
- Deployed and versioned independently from the main container
- Shares lifecycle and resource quota with the pod
- Common examples: Envoy proxies, log shippers, secrets agents