The Kubernetes reconciliation loop
the declarative control loop pattern.
a controller continuously observes actual state, compares to desired state in the spec, and acts to close the gap, level-triggered not edge-triggered.
What's really being asked
This checks whether you understand the declarative control loop that gives Kubernetes its self-healing behavior.
The full answer
A reconciliation loop is a continuous process: observe the actual state of the world, compare it against the desired state declared in an object's spec, and take action to drive actual toward desired, then repeat. Crucially it is level-triggered, meaning it acts on the current difference between desired and actual rather than reacting only to discrete events; this makes it robust to missed events, restarts, and drift because the next pass simply re-evaluates reality. The ReplicaSet controller embodies this: it watches Pods matching its selector, counts how many exist, and compares to the desired replica count. If too few exist it creates Pods; if too many, it deletes some. When a Pod dies, the next reconciliation observes the shortfall and creates a replacement, which is why workloads self-heal without explicit intervention.
The mistakes people make
Describing it as a one-time imperative action. Saying it is purely edge-triggered and only fires on events, which would miss drift. Confusing the controller with the scheduler. Thinking it requires manual reconciliation.
What usually comes next
What is the difference between level-triggered and edge-triggered? How does a controller watch for changes? What is the controller-manager? How does this pattern extend to Operators?
A concrete example
A ReplicaSet desires three replicas and three Pods run. A Node fails and one Pod disappears, so actual is two. On its next reconciliation, the ReplicaSet controller observes two against the desired three, creates one new Pod, and the scheduler places it on a healthy Node. State converges back to three without anyone intervening, and the same loop would delete a Pod if someone manually created a fourth.
Interview question
Why is the reconciliation loop described as level-triggered rather than edge-triggered?
- a.It fires exactly once per object creation
- b.It acts on the current gap between desired and actual state, so it corrects drift even if it missed eventsCorrect
- c.It only runs when an administrator triggers it manually
- d.It reacts only to Pod deletion events and nothing else
Why? this is the answer
Level-triggered means evaluating current state against desired on every pass, making it resilient to missed events and drift. Edge-only triggering (D) or one-shot runs (A) would fail to self-heal.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #controllers
- #reconciliation
- #replicaset
- #declarative
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles