ced4568andClaude Sonnet 5
25409d3bd7
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]>
49 lines
2.1 KiB
Markdown
49 lines
2.1 KiB
Markdown
# 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.
|