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.1
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:2
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.
Backend use case
Backend use case: this is the real lens for the repo’s Istio install, where backend services already run with Envoy sidecars and mesh metrics already feed operational systems like KEDA.
Common mistake
Common mistake: talking about Istio as if it replaces Kubernetes Services instead of layering L7 behavior on top of them.
Read this next
Istio docs — What is Istio? + Architecture
The service-mesh idea, and the data-plane/control-plane/istiod split. The canonical
starting point.
In plain English
Plain English: a service mesh adds routing, security, and telemetry to service traffic through sidecar proxies, without requiring application code changes.
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.