Sidecar Pattern

Also Known As

TL;DR

Explanation

A sidecar runs in the same Kubernetes pod as the main container, sharing its network namespace and storage. Common sidecars: Envoy proxy (service mesh — mTLS, tracing, retries), Filebeat/Fluentd (log shipping — reads app log files and forwards to aggregator), secret management agents (Vault agent injects secrets as files), and configuration reloaders. The sidecar pattern keeps the main application simple — it doesn't need to know about service mesh, log aggregation, or secret rotation. The pattern is the foundation of service mesh architectures.

Common Misconception

Why It Matters

Common Mistakes

• Sidecar with heavy resource usage stealing CPU/RAM from the main container — always set resource limits.
• Putting business logic in sidecars — sidecars are for cross-cutting infrastructure concerns only.
• Not handling sidecar startup ordering — main container may start before sidecar is ready.
• Too many sidecars per pod — each adds overhead; consolidate where possible.

Code Examples

// All concerns in the main container — bloated:
// PHP app must handle: TLS termination, log shipping,
// trace injection, secret rotation, health proxying
// Results in: large image, mixed concerns, hard to update each independently

# Kubernetes pod with sidecars:
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: php-app          # Main: pure business logic
    image: myapp:abc123
  - name: envoy            # Sidecar: mTLS + tracing
    image: envoyproxy/envoy:v1.28
  - name: filebeat         # Sidecar: log shipping
    image: elastic/filebeat:8.12
    volumeMounts:
    - name: logs
      mountPath: /var/log/app  # Reads PHP app logs

References

• ↗ https://kubernetes.io/docs/concepts/workloads/pods/#how-pods-manage-multiple-containers

Tags

Related Terms