Priority, preemption and disruption budgets
PriorityClass gives Pods a numeric importance. When a high-priority Pod cannot be scheduled because the cluster is full, the scheduler's PostFilter step checks whether evicting lower-priority Pods on some node would make room, and if so it evicts them (they get their normal graceful termination) and schedules the high-priority Pod there. Reveal the four steps with the right arrow.
A PodDisruptionBudget solves a different problem: voluntary disruptions such as kubectl drain, node upgrades and autoscaler scale-down. It states how many Pods of an application must remain available (minAvailable) or may be unavailable (maxUnavailable). The eviction API refuses to remove a Pod if that would violate the budget, so rolling node upgrades proceed at a safe pace.
The precise interaction to remember: the scheduler's preemption tries to honour PDBs when choosing victims, but PDB protection is not absolute against preemption. If there is no victim set that respects the budgets, preemption can still proceed to place a more important Pod. PDBs guarantee safety during voluntary operations; they are not a shield from priority.
Gotchas: a PDB that sets minAvailable equal to the replica count blocks all drains and stalls node upgrades; and a PDB on a single-replica Deployment means that Pod can never be evicted. Review PDBs before every upgrade, which Deck 6 covers in detail.