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]>
58 lines
3.2 KiB
Markdown
58 lines
3.2 KiB
Markdown
# Guided Exercise: Planning a Namespace Layout
|
|
|
|
This is a paper-and-thinking exercise — work through it before the Lab, not during it.
|
|
|
|
## The scenario
|
|
|
|
You're setting up a small Kubernetes cluster for a class project with three teams (`frontend`,
|
|
`backend`, `data`), each running their own set of Pods, and you also need a shared area for
|
|
tools everyone uses (a shared logging dashboard, for example).
|
|
|
|
## Your task
|
|
|
|
Sketch out, on paper or in a scratch file:
|
|
|
|
1. What Namespaces would you create, and why? (Hint: think about who needs to see what, and
|
|
whether any team's mistake — e.g. deleting the wrong Pod by accident — should be able to
|
|
affect another team.)
|
|
2. If `frontend` team members should be able to manage their own Pods but NOT touch `backend`'s
|
|
or `data`'s, what does that suggest about how Namespaces relate to access control? (You'll
|
|
learn the actual mechanism, RBAC, in ROOT 09 — for now just reason about why Namespace
|
|
boundaries make that kind of restriction possible at all.)
|
|
3. Would you put the shared logging dashboard in one of the three team Namespaces, or somewhere
|
|
else? Justify your answer.
|
|
4. If two teams both need to run something they each call `web`, what would happen if they were
|
|
in the SAME Namespace? What changes if they're in separate Namespaces?
|
|
|
|
## A reasonable answer to check yourself against
|
|
|
|
1. Three Namespaces (`frontend`, `backend`, `data`) — one per team, so each team's objects are
|
|
isolated from the others and a mistake in one Namespace (deleting the wrong Pod, applying a
|
|
bad manifest) can't accidentally affect a different team's workloads.
|
|
2. Namespace boundaries are what RBAC rules can be scoped TO — "this person can manage Pods in
|
|
the `frontend` Namespace" is a real, common permission model. Without separate Namespaces,
|
|
you'd have to distinguish access by resource name pattern instead of by boundary, which is
|
|
far more error-prone.
|
|
3. A separate Namespace (e.g. `shared-tools` or `platform`) — it isn't owned by any one team,
|
|
and mixing it into a team's Namespace would make it unclear who's responsible for it or
|
|
accidentally couple its lifecycle to that team's.
|
|
4. In the SAME Namespace, object names must be unique — a second `web` Deployment would either
|
|
fail to create or overwrite the first, depending on how it's applied. In SEPARATE
|
|
Namespaces, both `frontend/web` and `backend/web` can coexist without conflict — the
|
|
Namespace is part of what makes a name unique, not just the name itself.
|
|
|
|
If your answer differed meaningfully from this, re-read the lesson's Namespace section before
|
|
continuing to the Lab.
|
|
|
|
## Instructor Notes
|
|
|
|
**Facilitation:** Good as a 2-3 person small-group discussion in a live classroom before
|
|
revealing the reasonable answer — question 4 in particular often produces a genuine "oh" moment
|
|
once students realize name uniqueness is Namespace-scoped, not cluster-wide.
|
|
|
|
**Approximate timing:** 10 minutes live with discussion; 10 minutes self-paced.
|
|
|
|
**Optional extension:** ask what would need to be true for the `data` team to be ALLOWED to read
|
|
(but not modify) something in `shared-tools` — a good bridge to RBAC's read vs. write verbs,
|
|
covered properly in ROOT 09.
|