Lesson 2 · Service-mesh fundamentals

The sidecar & injection

How an Envoy proxy appears in your Pod and quietly takes over its network.

Your win: explain how the Envoy sidecar is added (automatic, namespace-based injection), how it transparently intercepts traffic, and this repo's revision-based setup and opt-outs.

The sidecar pattern

Recall Course 1: a Pod can hold more than one container, sharing a network namespace (one IP). Istio uses that. Alongside your build/server container, it adds an Envoy container — the sidecar. Because they share the Pod's network, Istio can reroute the Pod's traffic through Envoy: your app still connects to localhost, but Envoy intercepts inbound and outbound connections and applies the mesh's rules.1 Your code doesn't know it's there.

"Transparent" = you didn't change anything The interception is set up by init-time iptables rules (or the Istio CNI) that redirect the Pod's traffic to Envoy. That's the whole magic of Lesson 1's "no code changes": the sidecar is injected into the Pod spec and captures traffic — your app is unaware.

Injection — how the sidecar gets in

You don't add Envoy by hand. Automatic sidecar injection: a mutating admission webhook rewrites new Pods to include the Envoy container — but only in namespaces that have opted in via a label.2 The classic label is istio-injection=enabled; the newer, revision-aware form is istio.io/rev=<revision-tag> (so you can run multiple istiod versions and migrate namespaces one at a time).

Anchor — revision-based injection here This repo uses the revision form, not the plain label. istiod is installed with revision: 1-18-5 and a revisionTag of stable (prod) / local, with defaultRevision: 1-18-5 on istio-base (deployments/helm/platforms/istio/skaffold.yaml:16). A backend namespace opts in with istio.io/rev=stable, and every Pod there is auto-injected. The repo also tunes the sidecar's resources via pod annotations — sidecar.istio.io/proxyCPU: 10m, proxyMemory: 50Mi (libs/util/templates/_workload_metadata.tpl:16-17).
Anchor — deliberate opt-OUTS Not everything belongs in the mesh. Pods that set sidecar.istio.io/inject: "false" are kept out: the gandalf test/BDD pods (backend/gandalf/templates/deployment.yaml:20,77), and one-shot Jobs / CronJobs / migration hooks (Course 3 L7) — because a Job that runs to completion would otherwise hang forever waiting on a sidecar that never exits. Recognising when not to inject is a real operational skill.
A related setting you'll meet again The mesh config sets holdApplicationUntilProxyStarts: true (platforms/istio/istiod-values.yaml) — the app container waits for Envoy to be ready before starting, so early requests aren't sent before the sidecar can route them. A small but important ordering guarantee.
Read this next

Istio docs — Installing the sidecar (injection)

Automatic vs manual injection, the namespace label / revision tag, and how the webhook rewrites the Pod.

→ istio.io — Installing the Sidecar
→ istio.io — Data plane modes (sidecar vs ambient)

Check yourself (from memory)

Q1. The Envoy sidecar can intercept a Pod's traffic because…

Same Pod = same network (Course 1); iptables/CNI redirect the Pod's traffic through Envoy, transparently.

Q2. Automatic injection is triggered by…

A webhook injects Envoy into new Pods in labelled namespaces (istio.io/rev=stable here).

Q3. Why do this repo's Jobs and gandalf pods set inject: "false"?

A run-to-completion Job would hang waiting on a sidecar that never exits; gandalf is a test harness, deliberately outside the mesh.
How does the Envoy sidecar get injected and intercept traffic?
recall, then click to reveal
The SIDECAR is an Envoy container added to your Pod (shares the Pod's network namespace/IP, Course 1). init iptables/CNI rules redirect the Pod's inbound+outbound traffic THROUGH Envoy — TRANSPARENTLY (app talks to localhost, unaware). INJECTION is AUTOMATIC via a mutating webhook, gated by a NAMESPACE LABEL: classic istio-injection=enabled or revision-aware istio.io/rev=<tag>. REPO: revision-based (revision: 1-18-5, tag stable/local, defaultRevision on base); sidecar resources tuned via sidecar.istio.io/proxyCPU/Memory annotations. OPT-OUT with sidecar.istio.io/inject: "false" — gandalf test pods + Jobs/CronJobs/migration hooks (a Job would hang on a non-exiting sidecar). holdApplicationUntilProxyStarts makes the app wait for Envoy.
Want to see the iptables/CNI interception in detail, or why running two istiod revisions helps upgrades? Ask me.

1. Istio — Data plane modes.

2. Istio — Installing the Sidecar.