What is a PodDisruption Budget (PDB), and how does it protect application availability during voluntary disruptions like node drains?
Quick Answer
A PDB limits how many Pods of a workload may be unavailable simultaneously during voluntary disruptions (drains, cluster upgrades). It uses minAvailable or maxUnavailable against a label selector. Involuntary failures (node crash) are not blocked by PDBs.
Detailed Answer
Kubernetes distinguishes between involuntary disruptions—hardware failure, kubelet crash, network partition—and voluntary disruptions initiated by administrators or automation: kubectl drain, cluster autoscaler scale-down, rolling upgrades of node pools. PodDisruption Budgets exist solely to guard against voluntary disruptions eating too much capacity at once.
A PDB specifies either minAvailable (minimum Pods that must stay running) or maxUnavailable (maximum Pods that may be down) for Pods matching a label selector. When you drain a node, the eviction API checks every affected Pod against applicable PDBs. If evicting a Pod would violate the budget, the drain stalls until the situation resolves—either more Pods become ready elsewhere or an administrator adjusts the budget.
For payments-api running 3 replicas with a PDB of minAvailable: 2, Kubernetes permits only one Pod to be evicted at a time during maintenance. This ensures at least two instances continue serving traffic while the third reschedules. Without a PDB, a poorly timed node drain during peak checkout traffic could remove two or three replicas simultaneously, causing user-visible errors.
PDBs do not prevent involuntary failures. If an entire availability zone loses power, PDBs will not magically keep Pods alive. They also require matching labels between the PDB selector and the Pod template labels managed by the Deployment or StatefulSet controller. A common production mistake is creating a PDB whose selector matches no Pods, giving a false sense of protection.
An analogy: a PDB is like a fire code requiring two exits remain open during renovations. Contractors (drain operations) must pause if closing another exit would leave fewer than two open. It does not stop a sudden earthquake (involuntary failure)—that requires redundancy at the architecture level.
Pair PDBs with sensible replica counts. A single-replica Deployment with minAvailable: 1 makes drains impossible without force flags, which defeats the purpose. Always run at least N+1 replicas for workloads protected by minAvailable: N.