root-05-m00-kubernetes-mental-model — a new, full gold-standard-pattern front-door module for ROOT 05: what Kubernetes solves, the desired-state model, the control-plane/worker split, and Pods/Namespaces/labels through kubectl. Lesson, demonstration (watching a Pod get replaced after manual deletion), knowledge check, guided exercise (planning a Namespace layout), a real Lab (namespaces-basics), and a reflection — sequenced ahead of the existing bare kubectl-fluency lab bank. Co-Authored-By: Claude Sonnet 5 <[email protected]>
2.1 KiB
Knowledge Check: The Kubernetes Mental Model
Answer each question yourself before reading the answer that follows it.
1. You run kubectl delete pod on one Pod belonging to a Deployment with replicas: 3. A
few seconds later, kubectl get pods shows 3 Pods again, but one has a different name than any
of the original three. What actually happened?
Answer: The deleted Pod is gone permanently. The Deployment's controller noticed actual state (2 Pods) no longer matched desired state (3 Pods) and created ONE new Pod to close the gap. It is not the old Pod restarting — it's a brand new object.
2. A Deployment has replicas: 3, and there are 5 nodes in the cluster. Which of these
decides WHICH node each of the 3 Pods actually lands on?
Answer: The scheduler (part of the control plane), not the person who wrote the Deployment YAML and not the nodes themselves. You declare desired state; the scheduler makes the placement decision based on available resources and any placement rules configured.
3. True or false: kubectl communicates directly with the kubelet on whichever node your
Pod happens to be running on.
Answer: False. kubectl only ever talks to the API server (part of the control plane). The
API server is the single entry point for every read and write — it never bypasses the control
plane to reach a node directly for a normal get/apply/describe call.
4. Why is Kubernetes YAML described as "declarative" rather than a script?
Answer: A script describes a sequence of steps to execute once. Kubernetes YAML describes an END STATE you want to exist ("3 replicas of this container should be running") — a controller loop then continuously works to keep reality matching that description, correcting drift whenever it appears, indefinitely, not just once at apply time.
Instructor Notes
Facilitation: Ask these aloud in a live classroom before revealing answers — question 1 in particular tends to surface the "it restarted" misconception the demonstration activity should have already addressed; if it hasn't landed, this is the moment to circle back.
Approximate timing: 5 minutes.