Kubernetes Is a Control Loop, Not a Container Runner

The most useful reframe I can offer a junior engineer learning Kubernetes is this: it is not "containers at scale." It is a declarative control loop for failure management. The unit of work is not a container, it is a reconciliation. Every controller in the system runs the same shape of logic. Observe actual state, compare it to desired state, take an action to close the gap, repeat forever.

Once you see this, the feature list collapses. Liveness probes are a control loop that checks "is this pod still doing its job" and restarts if not. Readiness probes are a control loop that checks "should this pod receive traffic right now" and toggles its endpoint membership. Startup probes are a control loop that gates the other two until boot finishes. PodDisruptionBudgets are a control loop that limits how many pods a voluntary disruption is allowed to take down at once. Topology spread constraints are a control loop that re-evaluates placement against a desired distribution. They are not different features. They are different reconcilers expressing different desired states.

This is also why kubectl apply is not a command. It is a declaration. You are not telling Kubernetes "do this now." You are telling it "from now on, this is what reality should look like." The cluster will keep working toward that picture until you change it. If a node dies, pods get rescheduled. If a replica crashes, a new one comes up. If you scale from 3 to 6, the deployment controller notices the gap and creates three more. You did not issue six imperative create commands. You changed one number, and the loop did the rest.

The production failure I have watched eat hours of an incident: a team is firefighting and someone runs kubectl rollout restart deployment/web. Pods cycle. The cluster looks busy. The incident is not fixed. They run it again. Still broken. They run it five more times. Eventually pods hit CrashLoopBackOff and the team is convinced Kubernetes is "stuck." The actual problem was a ConfigMap pushed an hour earlier with a malformed database URL. Every restart pulled the same broken config because the desired state was wrong. Restarting was an imperative gesture aimed at a declarative system, and the system did exactly what it was told to do.

The fix is the mental flip. When something is wrong, do not ask "what command can I run?" Ask "what does the desired state say, and is it correct?" In a declarative system, the answer is almost always in the YAML, not in the shell.