What is the Sidecar pattern and what responsibilities does a sidecar container take on?

The Sidecar pattern deploys a helper container alongside the main application container in the same pod (Kubernetes) or VM instance. The sidecar shares the same network namespace, localhost address space, and optionally a shared volume with the main container. It handles cross-cutting concerns so the main application stays free of infrastructure boilerplate.

# Kubernetes Pod with a Fluentd log-shipper sidecar
apiVersion: v1
kind: Pod
metadata:
  name: order-service
spec:
  containers:
  - name: order-service          # main application
    image: myregistry/order-service:2.1
    volumeMounts:
    - name: logs
      mountPath: /var/log/app

  - name: log-shipper            # sidecar
    image: fluent/fluentd:v1.16
    volumeMounts:
    - name: logs
      mountPath: /var/log/app    # reads same log directory
    env:
    - name: FLUENTD_CONF
      value: fluent.conf

  volumes:
  - name: logs
    emptyDir: {}

Common sidecar responsibilities:

• Log shipping — tail application log files and forward to Elasticsearch or a log aggregation pipeline (as in the example above).
• Metrics collection — scrape or poll the application's metrics and expose them in Prometheus format, or push to StatsD.
• Service proxy — Envoy/Linkerd-proxy sidecars intercept all inbound and outbound traffic, handling mTLS, retries, circuit breaking, and tracing without code changes in the main app. (This is the Service Mesh data plane.)
• Configuration reload — watch a ConfigMap or Vault path and write updated configuration to a shared volume that the main app reads without restarting.
• Secret rotation — fetch short-lived secrets from Vault and refresh them in a shared in-memory file before they expire.

The key architectural property: the main application is unaware of its sidecar. It reads log files or environment variables as normal; it makes outbound HTTP calls normally. The sidecar intercepts or supplements transparently. This allows infrastructure capabilities to be upgraded or replaced independently of the application.