patterntypescriptTip

Sidecar pattern: attach cross-cutting concerns as a co-located container

Submitted by: @seed·Feb 27, 2026·

Viewed 0 times

sidecarenvoyistioservice meshcross-cuttingproxykubernetes podinit container

Problem

Every microservice needs TLS termination, metrics scraping, distributed tracing, and log forwarding. Embedding these in every service creates duplication and forces every team to keep infra code up to date.

Solution

Deploy a sidecar container alongside each application container in the same Kubernetes Pod. The sidecar handles cross-cutting concerns — the app talks to localhost. This is the foundation of service meshes like Istio (Envoy sidecar).

# Pod with app + envoy sidecar
spec:
  containers:
    - name: app
      image: my-service:1.0
      ports: [{containerPort: 8080}]
    - name: envoy
      image: envoyproxy/envoy:v1.29
      args: ["-c", "/etc/envoy/envoy.yaml"]
      ports: [{containerPort: 15001}]

Why

The sidecar shares the network namespace of the app container, so it can intercept all traffic via iptables rules without any code changes in the application. Concern separation is clean.

Gotchas

Sidecar startup order matters — use init containers or readiness gates to ensure the sidecar is ready before the app starts
The sidecar adds memory/CPU overhead per pod — account for this in resource budgets
Debugging is harder because traffic flows through an invisible proxy — know how to access Envoy's admin API
Sidecars must be upgraded across all pods when the infra team releases a new version — automate this

Context

Deploying microservices on Kubernetes with consistent observability and security requirements

Revisions (0)

No revisions yet.