Sidecar Injection

The Injection Mechanisms

 MANUAL: add the sidecar container to pod spec by hand.
         works; doesn't scale; drifts.

 AUTOMATIC (the norm): k8s ADMISSION WEBHOOK:
 
 1. pod created in labeled namespace
 2. API server calls istiod-class injector webhook
 3. webhook mutates pod: adds envoy container,
    init-container (iptables rules), volumes, ports
 4. pod schedules WITH mesh wiring baked in

 [kubectl apply] → [api-server] → [injector webhook]
                                        │ mutate
                                        ▼
                   pod = app + sidecar + net-redirects

 opt-in granularity: namespace label (mesh=enabled),
 per-pod overrides via annotations (opt-out for odd jobs).

The Init Container

 the piece people forget exists:

 runs BEFORE app starts; sets iptables/IPVS rules:
 - redirect outbound :80/:8080-ish traffic → sidecar port
 - redirect inbound service-port traffic → sidecar port
 - exclusions list (DNS, health-probe ports, metrics scrapes)

 consequences to know cold:
 □ app's OWN ports must not collide with sidecar ports
 □ excluded-port mistakes = traffic loops or bypassed mesh
 □ NET_ADMIN capability requirements surface here
   (why some restricted clusters struggle with classic meshes)

Operational Failure Modes

 injection failures and their signatures:

 webhook down/unreachable → pods start WITHOUT sidecars
   (silent! verify with sidecar-presence audits)
 webhook latency → pod startup stalls (webhook has timeout;
   failure-policy choice matters: Fail vs Ignore tradeoff)
 version skew: injected proxy ≠ control plane expected →
   pin versions; roll namespaces deliberately
 crash-looping sidecars → pod never ready; check resource
   limits FIRST (envoy OOM at startup is common misconfig)

 debugging ladder:
   kubectl get pod -o jsonpath={...containers}   # injected?
   kubectl logs <pod> -c istio-proxy --init      # wiring
   iptables-save inside pod                      # redirects

Rollout Strategy for Existing Fleets

 enabling mesh across live services safely:

 □ NAMESPACE BY NAMESPACE, starting with non-critical
 □ CANARY a service first: inject one deployment replica,
   compare error/latency profiles vs uninjected siblings
 □ WATCH the classics after each wave:
     startup time regression (extra container)
     mTLS peer mismatches (mixed fleet period — set
     PERMISSIVE mode then tighten)
     connection-pool exhaustion (new hop accounting)
 □ keep an OPT-OUT hatch per-pod during transition weeks

Interview Framing

“Enable the mesh across 200 existing deployments without incidents” scored shape: admission-webhook mechanics explained including init-container, failure modes named (webhook-down silent-skip is the star), permissive-mTLS migration path for mixed fleet, canary-per-service rollout plan, verification audits. Injection questions are secretly rollout-safety questions — answer with waves and hatches.