What is a pod disruption budget?
A pod disruption budget (PDB) is a Kubernetes object that limits how many pods of a replicated app can be down at the same time because of voluntary disruptions. It selects pods by label, and the eviction API refuses any eviction that would push the app below the budget.
Think of a restaurant that needs at least two waiters on the floor. The manager can send staff on breaks, but only one at a time, and nobody leaves while the floor is short.
Which disruptions does a PDB cover?
A PDB only limits evictions. Node drains for repairs, upgrades or scale-down use the eviction API, so they wait until the budget allows the next pod to go.
It does not stop involuntary disruptions such as a failed server, a kernel panic or a node running out of memory. Those still count against the budget, though. Deleting a pod or a Deployment directly also bypasses it, and rolling updates of a Deployment or StatefulSet follow their own settings instead.
minAvailable or maxUnavailable?
A PDB sets exactly one of two fields. Each takes a whole number or a percentage of the desired replicas.
minAvailable
The number of pods that must stay available after an eviction. With 5 replicas and minAvailable: 4, a drain can take one pod at a time. Percentages round up, so 50% of 7 pods means 4 must stay.
maxUnavailable
The number of pods that may be unavailable at once. A value of 1 keeps working when you scale the workload up or down, which makes it the easier choice for most Deployments.
Budgets that block drains
Some settings stop every voluntary eviction, and node drains hang until someone changes them:
- maxUnavailable: 0, or minAvailable equal to the replica count.
- A budget on a single-replica app that allows no disruption.
- Pods stuck in CrashLoopBackOff or never reporting Ready while the app is already short, under the default IfHealthyBudget policy. Setting unhealthyPodEvictionPolicy to AlwaysAllow lets drains evict them.
How enum handles pod disruption budgets
enum Kubernetes Engine runs upgrades node by node: each node is cordoned and drained, and its pods are evicted and start again on another node. Run at least two replicas and set a PDB, so each drain keeps enough of them serving. For how a blocking budget is handled during an upgrade, ask us.
FAQ
Does a PDB protect against a node failure? No. A PDB cannot prevent involuntary disruptions such as hardware failure or a kernel panic. It only limits evictions. Spread replicas across nodes so one failure does not take down every copy at once.
Should a single-replica app have a PDB? A budget that allows one disruption does not protect it, and a budget that allows none blocks every drain. Run two or more replicas instead, or accept short downtime during maintenance.
Can I use several PDBs for the same pods? Avoid it. When more than one budget selects the same pod, evictions of that pod fail. Keep one PDB per workload, with a selector that matches only that workload’s pods.