Lesson 1 · Service-mesh fundamentals

What a service mesh is

A layer that routes, secures, and observes service-to-service traffic — without touching your app code.

Your win: explain what a service mesh does, the split between the Envoy data plane and the istiod control plane, and why you'd add one on top of the Kubernetes Services you already have.

The gap a plain Service leaves

Course 2 gave you a Kubernetes Service: a stable name in front of Pods, doing basic L4 load-balancing. That's enough to reach a service — but it can't: route by request path, retry a failed call, split traffic for a canary, encrypt service-to-service traffic, or tell you the per-request latency and error rate. Those are L7 (application-layer) concerns. A service mesh is the infrastructure layer that adds them — and Istio's key trick is that it does so without changing your application code.¹

The one idea A mesh puts a proxy next to every Pod and routes all traffic through it. Because the proxy — not your app — handles routing, encryption, retries, and metrics, you get those capabilities across every service at once, by configuration, not by editing 25 codebases.

Two planes

Istio splits into a data plane and a control plane:²

CONTROL PLANE DATA PLANE ┌──────────────────┐ ┌───────────────────────────────┐ │ istiod │ push │ Pod: [ your app ]─[ Envoy ] │ │ discovery + │────────►│ Pod: [ your app ]─[ Envoy ] │ │ config→Envoy + │ config │ every Pod gets a │ │ Certificate Auth │ │ sidecar proxy │ └──────────────────┘ └───────────────────────────────┘

Plane	What it is	Does
Data plane	the Envoy proxies (one sidecar per Pod)	carries the traffic — routing, mTLS, retries, and emits telemetry
Control plane	istiod (one binary)	service discovery; turns your high-level rules into Envoy config and pushes it; acts as the CA that issues identities

You write intent (a VirtualService says "route /foo to service X"); istiod compiles it into low-level Envoy config and ships it to every sidecar. The sidecars do the work.

Anchor — Istio in this repo Istio (version 1.18.5) is installed as three Helm releases — istio-base, istiod, and istio-ingressgateway — under deployments/helm/platforms/istio/ (Course 3's Helm, again). Your gRPC services already run inside this mesh: each Pod has an Envoy sidecar, and the istio_requests_total metric that drives your KEDA autoscaling (Course 2 L9) is emitted by those sidecars. So you've been benefiting from the mesh without configuring it.

What this mesh is used for (set expectations now) Istio can do a lot; this repo uses it for a specific subset — traffic routing + edge TLS + telemetry. It deliberately does not turn on in-mesh mTLS or zero-trust authorization (we'll see why in Part 3). Good meshes are configured to what a team actually needs, not the full feature list — a useful thing to notice as we go.

Istio docs — What is Istio? + Architecture

The service-mesh idea, and the data-plane/control-plane/istiod split. The canonical starting point.

→ istio.io — What is Istio?
→ istio.io — Architecture

Check yourself (from memory)

Q1. A service mesh's defining trait is that it adds routing/security/telemetry…

A sidecar proxy next to each Pod handles it, so the capabilities arrive by config across every service — no code edits.

Q2. The data plane is made of…

Envoy sidecars carry the traffic. istiod is the control plane that configures them.

Q3. istiod's roles include…

istiod discovers services, compiles CRDs into Envoy config and pushes it, and issues mTLS identities as the CA.

What is a service mesh, and what are the two planes?

recall, then click to reveal

A SERVICE MESH is an infra layer that handles service-to-service comms — L7 ROUTING, SECURITY (mTLS), and TELEMETRY — WITHOUT changing app code, by putting a proxy next to every Pod. TWO PLANES: DATA PLANE = the ENVOY sidecar proxies (one per Pod; they carry traffic, do routing/mTLS/retries, emit metrics). CONTROL PLANE = ISTIOD (one binary: service discovery, compiles high-level CRDs → Envoy config and pushes it, and is the Certificate Authority for identities). It fills the gap a plain K8s Service leaves (L4 only). REPO: Istio 1.18.5, installed via 3 Helm releases (base/istiod/ingressgateway); services already run in the mesh; istio_requests_total (→ KEDA) comes from the sidecars. Used here for routing + edge TLS + telemetry, NOT mTLS/zero-trust.

Want to know how the sidecar intercepts traffic without app changes, or the difference between sidecar and "ambient" mesh mode? Ask me — injection is Lesson 2.

1. Istio — What is Istio?

2. Istio — Architecture (data plane, control plane, istiod).