Stop reading whenever you have enough
Istio architecture, in twelve questions.
Each one is the question the previous answer makes you ask. The ones that matter come with the command, because that is the part you meet at work.
Not technical? The first three questions are written for you, and they are enough to follow any conversation about this.
- Rungs
- 12
- Hands on
- 3
- Read
- ~8 min
What it is
01–03Hundreds of helpers carry the traffic. One brain tells them all what to do. This is the brain.
three minutes, no cluster needed · for anyone
- 01
What are the two planes?
Not knowing this costs
Confusing the planes produces exactly the wrong outage predictions.
- Data plane: the proxies, carrying every request
- Control plane: istiod, carrying only configuration
- User traffic never touches the control plane
- 02
What does istiod do all day?
Not knowing this costs
Config distribution and identity issuance, one process, both critical.
- Watches your YAML and the cluster state
- Translates both into per proxy Envoy config
- Signs the workload certificates, as the mesh CA
- 03
Why one process? I heard there were several.
Not knowing this costs
Old blog posts still describe the trio. The trio is history.
- There were: Pilot, Citadel, Galley, separate
- Operating three planes cost more than it isolated
- istiod merged them, on purpose, in 1.5
Before you scroll on
0/3You should now be able to
How config flows
04–05You write a small file. Seconds later every relevant helper behaves differently. This is the path between.
from your YAML to a proxy, end to end · for whoever applies manifests
- 04
What happens when I apply a VirtualService?
Not knowing this costs
No restarts anywhere on this path. That is the entire product.
- The API server stores it, istiod notices
- istiod recomputes config for affected proxies
- Each proxy receives its slice over xDS, in seconds
- 05
Does every proxy get the same config?
Not knowing this costs
In big meshes, every proxy knowing everything is the memory bill.
- No. Each gets the view relevant to it
- By default that view includes the whole mesh
- The Sidecar resource narrows it, and memory follows
Before you scroll on
0/3You should now be able to
Proving it works
06–08Two commands tell you whether the brain and the helpers agree.
commands that answer yes or no · for whoever has to sign it off
- 06
Do the brain and the helpers agree right now?
hands onNot knowing this costs
A drifted proxy fails no probe while running last week’s rules.
- proxy-status is the fleet wide answer
- SYNCED per channel, per proxy, or not
shellthe one command fleet checkistioctl proxy-status # NAME CDS LDS EDS RDS ISTIOD # checkout-x2k1.checkout SYNCED SYNCED SYNCED SYNCED istiod-7b4f-abc # legacy-batch-9z.jobs STALE SYNCED SYNCED SYNCED istiod-7b4f-abcSTALE on any channel means that proxy is serving older config than istiod pushed. It is the first command of every is-it-the-mesh conversation. - 07
A proxy disagrees. Whose version is wrong?
hands onNot knowing this costs
Guessing which side is stale wastes the first hour of the incident.
- Diff what istiod sent against what the proxy holds
- One command does exactly that comparison
shellthe tiebreakeristioctl proxy-status checkout-x2k1.checkout # given a single proxy instead of no arguments, proxy-status prints # the diff between what the proxy has loaded and what istiod would # send. Same command as the fleet check, narrowed to one pod.A persistent diff usually means the proxy NACKed an update it considers invalid. The istiod logs name the rejected resource. - 08
Is istiod itself healthy?
hands onNot knowing this costs
istiod ready and istiod accepting your config are different facts.
- It is a deployment like any other
- Watch push errors and rejected configs, not just readiness
shellplain kubernetes, plus two signalskubectl get deploy istiod -n istio-system kubectl logs deploy/istiod -n istio-system --tail=20 | grep -iE 'error|reject' # healthy: push and ads log lines, no rejections # trouble: "Push failed" or resource rejection with a nameReadiness green with rejections in the log is the sneaky state: istiod is up and refusing your newest config, which looks identical to your change not working.
Before you scroll on
0/3You should now be able to
When it breaks
09–10The brain going down is quieter than people expect, then louder than they planned for.
the outage everyone plans for wrong · for whoever gets paged
- 09
istiod goes down. What happens in the first minute?
Not knowing this costs
Panicking about live traffic in minute one aims the response wrong.
- Traffic: nothing. Proxies serve last config
- Existing routes, policy and mTLS all keep working
- The data plane does not need the brain to fly level
- 10
So what actually breaks, and when?
Not knowing this costs
The 24 hour certificate lifetime is the hard deadline on the outage.
- Immediately: config changes and new pod certificates
- New pods start without config, or not at all
- Within a day: certificate renewals start failing
Before you scroll on
0/3You should now be able to
Where it ends
11–12One brain per mesh has consequences worth saying out loud.
the limits, where people get caught · for whoever reviews the platform
- 11
What is controlling istiod equivalent to?
Not knowing this costs
Every mesh security claim rests on who can touch istio-system.
- It signs every identity and writes every rule
- Compromising it is compromising the mesh entirely
- Cluster admin and mesh admin are the same person
- 12
What does this page unlock?
Not knowing this costs
Upgrades, scaling and security all reason from this one diagram.
- Sidecar injection: how the proxies get there at all
- Production practice: running istiod like it matters
- Both assume the two plane picture from rung 1
Before you scroll on
0/3You should now be able to
Go deeper
3 links, each earning its place.