Pod Disruption Budgets
A PodDisruptionBudget (PDB) tells Kubernetes the minimum number or percentage of pods from a set that must remain available during voluntary disruptions, using either minAvailable or maxUnavailable. Operations that respect PDBs — node drains via kubectl drain, cluster autoscaler scale-downs, and the Eviction API in general — will refuse to evict a pod if doing so would violate the budget, protecting application capacity during routine cluster maintenance.
Cricket analogy: Like a franchise's contract requiring at least 4 of its 5 frontline bowlers to be available for any given match — the team management cannot rest more than one at a time for workload management, protecting the bowling attack's strength.
Voluntary vs Involuntary Disruptions
Kubernetes distinguishes voluntary disruptions — actions initiated deliberately through the API, like a node drain during an upgrade, a cluster autoscaler removing an underutilized node, or a manual pod eviction — from involuntary disruptions like a node crashing from hardware failure, a kernel panic, or an out-of-memory kill. PDBs only govern voluntary disruptions; they cannot prevent or throttle involuntary ones, which by nature happen outside any API-mediated, budget-checked process.
Cricket analogy: Like a planned rest day given to a bowler by team management ahead of a big series (voluntary) versus that same bowler suddenly pulling a hamstring mid-over (involuntary) — only the planned rest can be scheduled around a rotation policy.
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: checkout-api-pdb
spec:
minAvailable: 90%
selector:
matchLabels:
app: checkout-api
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: postgres-pdb
spec:
maxUnavailable: 1
selector:
matchLabels:
app: postgresminAvailable vs maxUnavailable
minAvailable specifies a floor — either an absolute number or a percentage — of pods that must stay Ready, while maxUnavailable specifies a ceiling on how many can be disrupted at once; you set exactly one, not both, on a given PDB. For a StatefulSet like a 3-node Postgres cluster where losing quorum is catastrophic, maxUnavailable: 1 is typical; for a large, horizontally scaled Deployment where you mostly care about aggregate capacity, minAvailable: 90% often expresses intent more naturally.
Cricket analogy: Like setting a required minimum of 4 fielders in the deep (minAvailable) versus setting a maximum of 2 fielders allowed to be pulled in for a specific tactical field change (maxUnavailable) — both approaches cap the same underlying disruption differently.
The Eviction API — used by kubectl drain, the cluster autoscaler, and node upgrade tooling — checks the relevant PDB before evicting a pod and returns a 429 Too Many Requests if the eviction would violate the budget, causing the caller to retry later rather than failing hard.
PDB Pitfalls
A PDB with minAvailable: 100% (or maxUnavailable: 0) mathematically forbids any voluntary disruption of that pod set, which will indefinitely block node drains and cluster upgrades until you either scale up first or temporarily relax the budget. Similarly, a single-replica Deployment protected by minAvailable: 1 has no slack at all — any drain of its node is permanently blocked unless the autoscaler or you manually intervene, since evicting the only pod would violate the budget.
Cricket analogy: Like a franchise rule stating 100% of the squad must always be fully fit and available with zero flexibility — in practice this means no player can ever be rested for injury management, grinding the rotation to a permanent halt.
Overly strict PDBs are a common cause of stuck node drains during cluster upgrades. Before an upgrade, audit PDBs with kubectl get pdb --all-namespaces and check ALLOWED DISRUPTIONS is greater than zero for critical workloads, or the drain will hang indefinitely waiting for a budget that can never be satisfied.
- A PDB sets minAvailable or maxUnavailable to protect availability during voluntary disruptions.
- PDBs govern voluntary disruptions (drains, autoscaler, manual eviction), not involuntary ones (crashes, OOM kills).
- Set exactly one of minAvailable or maxUnavailable per PDB, never both.
- The Eviction API checks PDBs and returns 429 rather than failing hard when a budget would be violated.
- minAvailable: 100% or maxUnavailable: 0 permanently blocks all voluntary disruption of that pod set.
- Single-replica workloads with a strict PDB have zero slack and will block node drains indefinitely.
- Always audit PDBs before cluster upgrades to avoid stuck, indefinitely-hanging node drains.
Practice what you learned
1. What does a PodDisruptionBudget primarily protect against?
2. Can you set both minAvailable and maxUnavailable on the same PDB?
3. What HTTP status does the Eviction API typically return when an eviction would violate a PDB?
4. What is the risk of setting minAvailable: 100% on a PDB?
5. Why is a strict PDB on a single-replica Deployment problematic?
Was this page helpful?
You May Also Like
Deployments In Depth
How Kubernetes Deployments manage ReplicaSets to deliver declarative rolling updates, rollbacks, and self-healing for stateless workloads.
StatefulSets Explained
How StatefulSets provide stable network identities, ordered lifecycle guarantees, and persistent per-pod storage for stateful applications.
DaemonSets Explained
How DaemonSets guarantee exactly one pod per matching node for node-level infrastructure like log collectors, monitoring agents, and CNI plugins.