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]>
49 lines
2.2 KiB
Markdown
49 lines
2.2 KiB
Markdown
# 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.
|