How to Configure Pod Disruption Budgets in Kubernetes

A PodDisruptionBudget (PDB) limits how many replicas of a workload can be down simultaneously due to voluntary disruptions — node drains, cluster upgrades, autoscaler scale-downs — protecting availability during planned operational events, distinct from involuntary failures a PDB has no control over.

Step 1: understand voluntary vs. involuntary disruption first

A PDB only governs voluntary disruptions — actions initiated deliberately, like draining a node for maintenance. It has no effect on involuntary disruptions like a node crashing unexpectedly or a pod being OOMKilled — those aren’t something a PDB can prevent.

Step 2: create a PDB specifying minimum available replicas

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: myapp

This guarantees at least 2 pods matching app: myapp remain available at all times during voluntary disruptions — kubectl drain on a node hosting one of these pods will respect this and wait rather than evicting a pod that would violate it.

Step 3: alternatively, specify maximum unavailable replicas

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp-pdb
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: myapp

maxUnavailable is often more convenient for a workload whose replica count changes over time (via autoscaling) — it scales the actual protection automatically rather than needing a fixed minAvailable number recalculated as replica count changes.

Step 4: apply the PDB

kubectl apply -f myapp-pdb.yaml

Step 5: verify the PDB’s current status

kubectl get pdb myapp-pdb

This shows ALLOWED DISRUPTIONS — the number of pods that could currently be voluntarily evicted without violating the budget, a directly useful number when planning a maintenance operation.

Step 6: test the PDB actually blocks an over-aggressive drain

kubectl drain <node-name> --ignore-daemonsets

If draining a node would evict enough pods to violate the PDB, the drain command blocks and waits rather than proceeding — confirming this behavior in a non-production test is worth doing before relying on it during a real maintenance window.

Step 7: use a PDB alongside a properly configured replica count

A PDB with minAvailable: 2 on a deployment running only 2 replicas total leaves zero tolerance for any voluntary disruption at all — the PDB and the actual replica count need to be considered together, not configured independently, for the budget to provide genuine flexibility during maintenance.

Step 8: check PDB status during an actual cluster upgrade or node maintenance event

kubectl get pdb -A

Reviewing this across all namespaces before a planned cluster-wide maintenance operation shows exactly which workloads have protection configured — and, implicitly, which ones don’t and might be more exposed to disruption during the maintenance window.

Why PDBs matter specifically during cluster upgrades and autoscaling events

Without a PDB, a node drain or cluster autoscaler scale-down has no built-in awareness of how many replicas of a given service it’s safe to take down at once — it could, in principle, evict every replica of a critical service simultaneously if they happened to land on nodes being drained together. A PDB is the mechanism that makes “always keep at least N replicas up” an enforced constraint during these voluntary operations, rather than a hope resting on replica placement working out favorably by chance.