Distinguish voluntary eviction from rollout availability
What This Concept Is
A PodDisruptionBudget constrains supported voluntary eviction requests. A Deployment rollout has its own availability/surge rules. Neither prevents an involuntary node outage.
Why It Matters Here
The availability lab must not treat a PDB as universal protection. It must also account for schedulable capacity and application data compatibility.
Concrete Example
With three healthy replicas and integer minAvailable 2, an otherwise eligible eviction can reduce healthy replicas to two; a second should be blocked until sufficient health returns. This simplified prediction assumes no other disruption and current status. A failed node can still remove multiple replicas. A Deployment can conduct a rollout under its own settings; the PDB does not gate its rolling updates.
Common Confusion / Misconception
A budget is not spare capacity. A replacement Pod can remain Pending because of requests, affinity or storage constraints. Deleting Pods directly is not the same experiment as requesting eviction.
How To Use It
Capture the controller and scheduler evidence for an eviction, bad-image rollout and node-loss scenario separately. Record old/new revision counts, availability, placement and workload behavior. State which operation the control actually limits.
Check Yourself
Can maxSurge schedule a Pod when no node has room? Which actor handles eviction? Does one surviving process guarantee enough capacity?
Mini Drill or Application
Run the original bad-image rollback. Add a constrained-capacity case and explain whether it is a scheduling, readiness or disruption-policy problem.
Read This Only If Stuck
Building Secure and Reliable Systems provides selective operational reasoning. Use the module sources below for current tool behavior; do not read a whole book before attempting the exercise.