Files

T

ced4568andClaude Sonnet 5 25409d3bd7 feat(root): author Kubernetes foundations curriculum

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]>

2026-08-26 09:05:40 -05:00

3.2 KiB

Raw Blame History

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:

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.)
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.)
Would you put the shared logging dashboard in one of the three team Namespaces, or somewhere else? Justify your answer.
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

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.
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.
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.
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.

3.2 KiB Raw Blame History