Platform & DevOps·topic 2 of 9
The orchestrator's model of the world
You stop telling the machine what to do and start telling it what you want, and something else spends the rest of the day closing the gap. Almost every surprising thing an orchestrator does follows from that one swap, and this is the vocabulary of it.
Read in order · tick what you already know
- 01
the API that decides what should run went down, and everything already running carried on serving traffic perfectly.
Control plane
- 02
the nodes running your containers and the proxies moving the packets keep working whether or not anyone is watching them.
Data plane
- 03
a machine joins the pool, advertises how much CPU and memory it has, and starts being given other people's workloads.
Node
- 04
you stopped addressing individual machines and started submitting work to a pool that decides where it lands.
Cluster
- 05
you ran the commands in order, and doing it again would create a second copy of everything.
Imperative configuration
- 06
you write down what should exist, submit it, and something else works out the steps — including that most of them are already done.
Declarative configuration
- 07
you said three replicas, and every time someone deletes one a fourth appears without anybody being asked.
Desired state
- 08
the spec says three and the status says one, and the gap between those two numbers is the entire incident.
Observed state
- 09
something reads the difference between what you asked for and what exists, takes one step to close it, and then does it all again forever.
Reconciliation loop
- 10
you never create the individual containers; you create an object, and a background process creates them to match it.
Controller
- 11
the failover, the backup and the version upgrade for the database are performed by software encoding what the DBA used to do.
Operator
- 12
your team's own object type — a queue, a tenant, an environment — is created the same way as anything else and reconciled by your own controller.
Custom resource
- 13
you asked for the workload to run somewhere, and something scored every node and picked one before any container existed.
Scheduler
- 14
two containers share an IP address and a lifetime, and are scheduled onto the same node together or not at all.
Pod
- 15
a second container next to your application handles TLS, logging or metrics, and your code was never changed.
Sidecar
- 16
a throwaway container runs the migration, finishes, and only then does the application container start.
Init container
- 17
the log collector appears on every node automatically, including the one that joined the cluster four minutes ago.
DaemonSet
- 18
the replicas are named zero, one and two rather than randomly, and each one gets its own disk back after a restart.
StatefulSet
- 19
the pod died, came back on another node, and the data was still there because the disk followed it.
Persistent volume