💼 Kubernetes Interview Q&A

Kubernetes Interview Q&A: 🎬 The Most-Asked Interview Question: How the Control Loop Works If the Controller Dies If an interview asks "summarize Kubernetes in one sentence," the

🎬 The Most-Asked Interview Question: How the Control Loop Works

If the Controller Dies

If an interview asks "summarize Kubernetes in one sentence," the right answer is "it is a collection of control loops." This film brings to life the mechanism behind that one sentence — perhaps the single most-asked Kubernetes interview question.

Step 1 — every control loop starts with a GOAL: "there should be 3 replicas," "this Service should route to those Pods." This goal always lives in etcd, never hardcoded in code.

Step 2 — the Controller does NOT run once and finish like a script; it continuously "watches" the API Server — it is notified instantly on any change, it does not poll once a second.

Step 3 — when watch reports a change, the Controller kicks in: it computes the gap between "actual state" and "desired state." If the gap is zero, it does nothing — this prevents wasted work.

Step 4 — if there is a gap (e.g. a missing Pod), the Controller sends a corrective request and actual state moves back toward the target. This loop is INFINITE — it never says "done," it repeats forever.

Final (the contrast) — the common interview follow-up is: "what if the Controller itself crashes?" Answer: actual state does not break INSTANTLY, but no one corrects new drift — it accumulates SILENTLY until the controller comes back up. This is why the Controller Manager itself is watched as a Pod/Deployment by Kubernetes and restarted when needed.

The Control Loop: An Endless Comparison Loop

The controller reads the desired state from etcd through the API Server.

Actual state is read

What is currently running in the cluster is observed (how many Pods, in what state).

It is compared whether there is a gap between target and actual.

A corrective request is sent