Kubernetes
Why does Kubernetes use desired state instead of commands?
Short answer
Because over an unreliable network you cannot know whether a command arrived. Declaring the intended end state makes that uncertainty harmless — the same declaration can be applied any number of times and the result is identical.
The constraint behind it
Every instruction to a distributed system crosses a network that can drop, delay or duplicate it. When a request times out, the sender genuinely does not know whether it succeeded, failed, or is still in flight.
For a command like "create one more replica", that ambiguity is unrecoverable. Retrying might create a second one. Not retrying might leave you short. There is no way to tell which, because the information you need is on the other side of the failure.
Declaring "there should be three replicas" removes the problem entirely. Send it once or a hundred times; the outcome is three replicas. The uncertainty still exists, but it no longer matters.
◈ If it were the other way
What that system would look like
A command-based cluster would need every instruction to be exactly-once, which over a network means sequence numbers, acknowledgements, deduplication and a durable log of what has been applied — effectively a distributed transaction for every scaling operation.
And drift would have nowhere to go. If a pod dies, no command was issued, so nothing happens. Recovery would require something to notice the discrepancy and issue a corrective command — which is a reconciliation loop, arrived at reluctantly and with worse guarantees.
Configuration management tools took the command path first and mostly converged on declarative models for exactly this reason.
◆ What it buys you
- Idempotency for free. `kubectl apply` twice does what it did once, which is why GitOps works at all — a git repository is a declaration, replayed continuously.
- Self-healing as a side effect rather than a feature. The controller does not distinguish "a pod died" from "you asked for one more"; both are just a gap between desired and actual.
- Auditability. The declaration is the intent, so reviewing a diff tells you what will be true, not what will be attempted.
◑ What it costs you
- Everything is eventually consistent. `kubectl apply` returns when the declaration is *accepted*, not when it is true, which is why `rollout status` exists as a separate thing to wait on.
- Failures are asynchronous and appear somewhere else. A manifest is accepted, and the reason it cannot be satisfied shows up minutes later in pod events.
- Imperative operations are awkward. "Restart this deployment" is not a declaration, which is why the idiom is to patch an annotation and let the diff trigger a rollout — a workaround that reveals the model's edge.
Where it bites in practice
When something silently does not happen. A manifest applies cleanly, and nothing runs. There is no error, because accepting a declaration and satisfying it are different steps — and the reason lives in `kubectl describe`, in events, rather than in the response to the command you ran.
What comes next
Did this get you to an answer?
No text box on purpose — please do not paste production logs anywhere