feat(root): add storage and scheduling curriculum

Two new PARTIAL modules, moving ROOT 08 off PLANNED for the first time: root-08-m01-storage-fundamentals — ephemeral vs. persistent storage, PV/PVC/StorageClass. Lesson + knowledge check + real Labs (emptydir-pod, pv-pvc-mount, pvc-dynamic-task, storageclass-mcq). root-08-m02-scheduling-resource-governance — how the scheduler places Pods and how quotas/limits/priority/disruption budgets shape that placement. Lesson + knowledge check + real Labs (node-label-selector, node-taint-toleration, pod-affinity-mcq, priority-class-task, pod-disruption-budget-task, resource-quota-ns, limitrange-task). cluster-upgrade-mcq and etcd-backup-mcq deliberately left unwired — ROOT 11/DevOps territory, out of this phase's scope, not overlooked. Co-Authored-By: Claude Sonnet 5 <[email protected]>
2026-08-26 09:06:43 -05:00
parent dbcc210889
commit 73cea1ba1d
4 changed files with 252 additions and 0 deletions
@@ -0,0 +1,74 @@
+# Ephemeral vs. Persistent Storage
+
+## The default: a container's filesystem is thrown away
+
+By default, anything a container writes to its own filesystem disappears the moment that
+container is replaced — a crash, a rollout, a reschedule, anything. This is a deliberate design
+choice (it's part of what makes a Pod safely disposable/replaceable), but it means "just write
+files to disk" silently loses data unless you use one of Kubernetes' actual storage mechanisms.
+
+## emptyDir: shared, but still temporary
+
+An `emptyDir` volume gives a Pod's containers a shared directory that survives a container
+restart WITHIN the same Pod, but is deleted the moment the Pod itself is removed. It's the right
+tool for two containers in one Pod that need to share files with each other (a sidecar writing
+logs another container reads, for example) — not for anything that needs to outlive the Pod.
+
+```yaml
+volumes:
+- name: shared-data
+  emptyDir: {}
+```
+
+## PersistentVolume & PersistentVolumeClaim: storage that outlives the Pod
+
+A **PersistentVolume (PV)** represents an actual piece of storage (a cloud disk, an NFS share,
+whatever the cluster's infrastructure provides) as a Kubernetes object. A
+**PersistentVolumeClaim (PVC)** is a Pod's REQUEST for storage matching some criteria (size,
+access mode) — the Pod references the PVC, not a PV directly, and Kubernetes binds the PVC to a
+matching PV.
+
+```
+Pod  ──references──>  PVC ("I need 5Gi, ReadWriteOnce")  ──binds to──>  PV (actual storage)
+```
+
+This indirection matters: a Pod's manifest doesn't need to know or care exactly which physical
+storage backs its PVC — that's resolved separately, and the same PVC keeps working even if the
+Pod behind it is replaced.
+
+## StorageClass & dynamic provisioning
+
+Manually creating a PV for every PVC doesn't scale. A **StorageClass** describes a category of
+storage (e.g. "fast SSD" vs. "cheap archival") and, when a PVC requests that class, the cluster
+can automatically provision a matching PV on demand — this is "dynamic provisioning," and it's
+the normal way storage works on any real cloud-hosted cluster. A StorageClass also controls the
+**reclaim policy** — what happens to the underlying storage after its PVC is deleted (`Delete`
+the data, or `Retain` it for manual recovery).
+
+## The decision in one pass
+
+| You need... | Use |
+|---|---|
+| Temporary scratch space shared between containers in ONE Pod | `emptyDir` |
+| Storage that survives Pod replacement, manually provisioned | PV + PVC |
+| The above, provisioned automatically on demand | PVC + StorageClass (dynamic provisioning) |
+
+## Instructor Notes
+
+**Approximate timing:** 15 minutes read; 10 minutes live with the PV/PVC/StorageClass diagram.
+
+**Likely misconceptions to watch for:**
+- Students often assume `emptyDir` is "persistent" because the name doesn't obviously say
+  otherwise. Be explicit: it survives a CONTAINER restart, not a POD deletion.
+- The PV/PVC indirection can seem like unnecessary ceremony at first — frame it as the same
+  "declare what you want, let the system resolve it" pattern from ROOT 05's desired-state
+  lesson, applied to storage instead of Pod count.
+
+**Discussion question:** "If a Pod using a PVC is deleted and replaced, what happens to its
+data?" (Answer: it's preserved — the PVC and its bound PV are separate objects from the Pod,
+and a new Pod referencing the same PVC picks up right where the data was left, which is the
+entire point of using persistent storage over `emptyDir`.)
+
+**Optional extension:** ask what a `Retain` reclaim policy is protecting against, compared to
+`Delete` (answer: accidental data loss from deleting a PVC by mistake — `Retain` keeps the
+underlying storage around for manual recovery instead of immediately destroying it).
@@ -0,0 +1,44 @@
+# Knowledge Check: Storage Fundamentals
+
+---
+
+**1. Two containers in the same Pod need to share files with each other, but nothing needs to
+survive the Pod being replaced. What's the simplest correct choice?**
+
+*Answer:* `emptyDir` — shared within the Pod, deliberately temporary, exactly matching the
+requirement. Reaching for a PV/PVC here would be more machinery than the problem needs.
+
+---
+
+**2. A Pod using a PVC is deleted and a new Pod is created referencing the SAME PVC. What
+happens to the data?**
+
+*Answer:* It's preserved. The PVC and its bound PV exist independently of any specific Pod — the
+new Pod picks up exactly where the data was left, which is the entire reason to use persistent
+storage instead of `emptyDir` for anything that needs to outlive a single Pod's lifetime.
+
+---
+
+**3. True or false: a Pod's manifest must specify exactly which PersistentVolume backs its
+storage request.**
+
+*Answer:* False. A Pod references a PVC (a request), not a PV directly — the binding between
+PVC and an actual PV is resolved separately, which is exactly the indirection that lets the same
+Pod manifest work regardless of which physical storage ends up behind it.
+
+---
+
+**4. What does a StorageClass's reclaim policy actually control, and why would a team choose
+`Retain` over `Delete` for a production database's storage?**
+
+*Answer:* It controls what happens to the underlying storage after its PVC is deleted. `Retain`
+keeps the data around for manual recovery instead of immediately destroying it — a safety
+margin against an accidental `kubectl delete pvc` on something genuinely important, at the cost
+of needing manual cleanup later.
+
+## Instructor Notes
+
+**Facilitation:** Question 2 is worth confirming lands correctly — it's the single fact that
+justifies the entire PV/PVC indirection existing at all.
+
+**Approximate timing:** 5 minutes.