Sidecar Pattern
debt(d7/e7/b7/t3)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints note automated=no and the code_pattern describes PHP containers handling cross-cutting concerns directly — this is only visible through architecture review or observing runtime symptoms (resource contention, startup race conditions, missing trace headers). Kubernetes, Docker, Envoy, and Fluent-bit are listed tools but none automatically flag misuse of the sidecar pattern itself.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix describes deploying a sidecar alongside the PHP container, but common_mistakes show multiple systemic issues: resource limits across all pods, startup ordering across services, consolidating sidecars, and removing business logic from sidecars. Correcting a poorly applied sidecar pattern requires touching pod definitions, deployment manifests, and potentially application code across many services — this is a cross-cutting infrastructure refactor.
Closest to 'strong gravitational pull' (e7). The applies_to covers both web and cli contexts, and the pattern is tagged across architecture, kubernetes, devops, and microservices. Once sidecars are in place (or incorrectly absent), every future pod definition, deployment, and operational concern is shaped by this choice. Resource limits, startup ordering, and separation of concerns are ongoing taxes paid by every team member working on the system.
Closest to 'minor surprise (one edge case)' (t3). The misconception is specific and well-documented: developers assume sidecars share the main container's filesystem, but actually they only share the pod's network namespace and explicit volumes. This is a notable but narrow edge case — it doesn't contradict a broader category of concepts, and most experienced Kubernetes developers learn this distinction relatively quickly.
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