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]>
2.2 KiB
Knowledge Check: Scheduling & Resource Governance
1. A node is tainted dedicated=gpu:NoSchedule. A Pod with no matching toleration is
pending and never gets scheduled anywhere else, even though other untainted nodes have free
capacity. What's actually going on?
Answer: Nothing is wrong — the taint only affects the tainted node specifically; it doesn't explain why the Pod isn't landing elsewhere. If it's stuck pending entirely, the cause is something else (insufficient resources cluster-wide, a nodeSelector/affinity rule that can't be satisfied anywhere) — the taint itself only ever repels from the ONE node it's applied to.
2. During a planned node drain for maintenance, would you expect a PodDisruptionBudget to prevent an UNRELATED node from crashing unexpectedly at the same time?
Answer: No. A PDB only constrains VOLUNTARY disruptions — operations Kubernetes/an operator controls the timing of, like a drain. An unrelated hardware failure is involuntary and ignores PDBs entirely; nothing is "asking permission" for a crash.
3. True or false: a higher-priority pending Pod can cause a lower-priority, already-RUNNING Pod to be evicted to make room.
Answer: True — this is what Pod priority/preemption actually does under resource pressure, not just a scheduling hint. Misconfigured priorities can have real, disruptive consequences for this reason.
4. A team notices new Pods in their Namespace keep getting created with no CPU/memory requests at all, even though nobody set that intentionally. What governance mechanism would fix this going forward, and what would it NOT fix?
Answer: A LimitRange with default requests/limits would apply sensible defaults to future Pods created without explicit values. It would NOT retroactively change Pods that already exist — it only affects new Pod creation from the point it's added.
Instructor Notes
Facilitation: Question 2 reinforces a genuinely important, often-missed distinction (voluntary vs. involuntary disruption) — worth confirming it lands, not just that the answer was guessed correctly.
Approximate timing: 5-7 minutes given the density of this module's lesson.