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]>
45 lines
2.4 KiB
Markdown
45 lines
2.4 KiB
Markdown
# Reflection: Why Desired State Matters in Production
|
|
|
|
You just created an isolated Namespace and a Deployment with a declared replica count. Take a
|
|
few minutes to connect this to why it matters beyond passing this Lab's validation.
|
|
|
|
## Reflection questions
|
|
|
|
1. If your `team-alpha` Namespace were a real team's production environment, what's one mistake
|
|
in a DIFFERENT namespace that Namespace isolation would have protected you from?
|
|
2. You declared `replicas: 2` rather than manually creating two Pods. What would you have had
|
|
to do manually, over and over, if Kubernetes only supported creating individual Pods with no
|
|
concept of desired state?
|
|
3. Think of one non-Kubernetes system you've used (a thermostat, a spell-checker, an
|
|
auto-save feature) that also works by continuously comparing "what is" to "what should be."
|
|
What made you think of it?
|
|
|
|
## Real Ops takeaway
|
|
|
|
**Namespaces are your first real production safety boundary, and they're free.** A
|
|
misconfigured `kubectl delete` scoped to the wrong Namespace is a common, entirely preventable
|
|
class of incident — teams that consistently namespace their environments (dev/staging/prod, or
|
|
per-team) limit the blast radius of almost any operator mistake to just that Namespace. This
|
|
costs nothing to set up and prevents a real, common category of outage.
|
|
|
|
**Desired state is what makes self-healing possible at all.** Every "the platform recovered on
|
|
its own" story you'll hear about Kubernetes in production traces back to exactly the mechanism
|
|
you just watched in the demonstration: a controller comparing actual state to desired state and
|
|
correcting the gap. Understanding this loop is what lets you predict Kubernetes' behavior
|
|
instead of being surprised by it.
|
|
|
|
This module is complete. Continue to the next module.
|
|
|
|
## Instructor Notes
|
|
|
|
**Discussion questions for a live classroom:** use all three reflection questions as discussion
|
|
prompts. Question 3 in particular tends to produce good analogies that make the abstract
|
|
"controller loop" concept concrete and memorable.
|
|
|
|
**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced writing.
|
|
|
|
**Optional extension:** ask students to name one place in their own life (not computing) where
|
|
"declare the goal and let a system enforce it" would work better than "manually do the thing
|
|
every time" — a genuinely reflective prompt that reinforces the mental model beyond Kubernetes
|
|
specifically.
|