Desired State
You don't hand Kubernetes a procedure; you declare a result. Write down that there should be three web servers, and a controller keeps looking at what's actually running and closes the gap whenever reality differs. When a node dies and a Pod vanishes, nobody issues a repair command. The mere fact that there are two where there should be three is what creates a new Pod.
01Desired State
Concept at a GlanceDeclare that there should be three web servers. Not how to build them — only how many there must be — hand that to the API server, and the declaration lands in etcd.
The controller compares the declaration with reality. Wanted: three. Running: none. Three short.
Where the new Pods go is the scheduler's call. Looking at free capacity, it splits them across the two nodes.
Each node's kubelet starts the containers it was given. Two on node 1, one on node 2 — three, as declared.
Node 2 stops responding. web-3, which ran there, is gone with it, leaving only two.
Nobody issues a repair command. The controller simply counts again and notices there are only two.
It creates the missing one and places it on a living node. The declaration was three the whole time.
Try it yourself
Click a Pod to delete it, click a node to kill it · the count comes back without you pressing anything
Declared three, running three — the loop has nothing to do
02 Understand It Simply
For EveryoneYou declare the state you want, and a controller keeps comparing it with the current state and closing the gap. You record the result rather than dictating the procedure.
The declared state is stored in the API server, and controllers repeatedly compare it with the observed state.
Creating what's missing and removing what's extra, over and over, is the control loop.
Where a new Pod goes is the scheduler's call, and the node's kubelet actually starts the container.
Because recovery comes from comparing state rather than handling events, a missed notification still gets reconciled on the next pass.
It isn't instant, though: when a node stops responding, Kubernetes waits a while (roughly five minutes by default) before clearing out its Pods, and only then is the shortfall made up.
- –Tracing how automatic recovery happens during an outage
- –treating deploys and rollbacks as state declarations
- –and understanding why kubectl apply is a declaration rather than a command
03 Frequently Asked Questions
FAQWhat is Desired State?+
You don't hand Kubernetes a procedure; you declare a result. Write down that there should be three web servers, and a controller keeps looking at what's actually running and closes the gap whenever reality differs. When a node dies and a Pod vanishes, nobody issues a repair command. The mere fact that there are two where there should be three is what creates a new Pod.
Where is Desired State used?+
Tracing how automatic recovery happens during an outage, treating deploys and rollbacks as state declarations, and understanding why kubectl apply is a declaration rather than a command.
What's a simple analogy for Desired State?+
You declare the state you want, and a controller keeps comparing it with the current state and closing the gap. You record the result rather than dictating the procedure.