Two Kinds of Disruption
Pods can be terminated for two fundamentally different reasons:
Involuntary disruptions are failures you cannot predict or prevent: a physical server loses power, a kernel panic crashes a node, the node runs out of memory and the OOM killer terminates Pods. You handle these with replicas, health checks, and multi-zone deployments.
Voluntary disruptions are intentional actions taken by cluster operators or automation: draining a node to apply a security patch, upgrading the Kubernetes version, scaling down the cluster to reduce costs, or evicting Pods to rebalance resource usage. These are planned and controllable.
The key insight: you can't stop hardware failures, but you can negotiate with Kubernetes about how many Pods it's allowed to take down at once during planned maintenance.
What a Pod Disruption Budget Does
A Pod Disruption Budget (PDB) is a policy object that limits the number of Pods of a replicated application that can be simultaneously unavailable due to voluntary disruptions. It does not protect against involuntary disruptions.
You define a PDB using one of two fields:
minAvailable: The minimum number (or percentage) of Pods that must remain available. Kubernetes will block voluntary evictions that would violate this.maxUnavailable: The maximum number (or percentage) of Pods that can be simultaneously unavailable.
A PDB is mostly a selector (which Pods it applies to) and one of those two fields — minAvailable accepts either a fixed count or a percentage of the matched Pods.
How It Works in Practice
When a cluster operator drains a node to prepare it for maintenance, the drain process attempts to evict all Pods on that node. Before evicting each Pod, Kubernetes checks whether the eviction would violate any PDB. If evicting the Pod would bring the available count below minAvailable, the eviction is blocked — kubectl drain will wait or return an error.
This forces the operator to either wait for the application to recover (if other Pods are unhealthy for unrelated reasons) or consciously override the PDB with --disable-eviction. The PDB acts as a safety gate that prevents accidental outages during routine maintenance.
Example scenario: You have 5 replicas of a web app and a PDB with minAvailable: 4. A node drain tries to evict 2 Pods simultaneously (because both happen to be on the same node). Kubernetes will evict the first Pod (5 → 4, still satisfies the PDB), then block the second eviction until the first Pod is rescheduled and becomes Ready elsewhere (4 → 5 again), then allow the second eviction (5 → 4).
Interviewers ask: "How do you ensure zero downtime during node maintenance?" The answer involves multiple layers: PodDisruptionBudgets to control eviction rate, minReadySeconds on Deployments to ensure new Pods are actually serving traffic before old ones are removed, and Pod anti-affinity rules to spread replicas across nodes so a single node drain never takes down all replicas. PDBs alone are not sufficient if all your replicas happen to be on the same node.