ced4568andClaude Sonnet 5
73cea1ba1d
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]>
45 lines
1.8 KiB
Markdown
45 lines
1.8 KiB
Markdown
# 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.
|