What is the sidecar container pattern, and what problems does it solve?

The pattern

apiVersion: v1
kind: Pod
metadata:
  name: app-with-proxy
spec:
  containers:
    - name: app
      image: myapp:1.0
      ports:
        - containerPort: 8080
    - name: envoy-proxy      # sidecar
      image: envoyproxy/envoy:v1.28
      ports:
        - containerPort: 9901

Both containers share the Pod's single network namespace, so the sidecar can transparently intercept, inspect, or modify traffic to/from the main container (e.g., a service mesh proxy handling mTLS encryption and traffic routing) without the application itself needing any awareness that a proxy is involved — from the application's point of view, it just talks to localhost or receives connections normally.

Problems this pattern solves

• Cross-cutting infrastructure concerns, applied uniformly, without touching application code. A service mesh (Istio, Linkerd) injects an Envoy sidecar into every Pod to handle mTLS, retries, circuit breaking, and traffic metrics — none of which the application code needs to implement itself, and all of which can be upgraded/reconfigured centrally without redeploying every application.
• Log/metrics shipping — a sidecar that tails the main container's log files (via a shared volume) and forwards them to a centralized logging system, decoupling "how do I ship my logs" from the application's own code.
• Dynamic configuration reloading — a sidecar that watches a ConfigMap-mounted file for changes and signals the main container to reload, without the main application needing to implement file-watching logic itself.
• Ambassador/adapter pattern (a close relative) — a sidecar that simplifies how the main container talks to an external service, e.g., proxying a simple local connection to a complex external API with its own authentication.

Why this is better than baking the same logic into every application's image

Without sidecars, every team building an application would need to implement its own logging shipment, mTLS handling, and metrics export — duplicated effort, inconsistent implementations across teams, and a much larger blast radius when that cross-cutting logic needs to be updated (every application's image needs a rebuild, instead of just redeploying a shared sidecar image). The sidecar pattern lets a platform/infrastructure team own and evolve this logic centrally, injected uniformly across every application.

The formalization of "sidecar" as a first-class Kubernetes concept

Historically, "sidecar" was purely a convention — just a second container in a Pod, with no special Kubernetes-level distinction from the main container. Kubernetes 1.28+ introduced native support for explicitly marking a container as a sidecar (via restartPolicy: Always on an entry under initContainers), which gives it defined startup-ordering semantics (starts before the main containers, similar to an init container, but keeps running for the Pod's whole lifetime) and proper shutdown ordering (a true sidecar is terminated after the main containers during Pod shutdown, so it can keep shipping logs/metrics during the main container's graceful shutdown) — before this, achieving correct shutdown ordering for sidecars required careful manual workarounds.

The cost of the pattern

Every sidecar adds resource overhead (CPU/memory requests for a container running in every single Pod, multiplied across your whole fleet) and a bit of additional complexity to reason about (two containers' worth of logs and failure modes per Pod instead of one) — worth it for genuinely cross-cutting concerns that benefit from centralized ownership, but not a pattern to reach for casually for logic that's simple enough to just belong in the application itself.