What is a Kubernetes PodDisruptionBudget, and which kinds of pod loss does it actually protect against?

## The problem it solves Cluster maintenance means pods move. A node gets a new kernel, a node pool rolls to a new image, the cluster autoscaler consolidates two half-empty nodes into one. Without coordination, an automated drain can take out every replica of a service at once — each individual eviction looks harmless, and the aggregate is an outage. A PodDisruptionBudget is how a workload owner tells the cluster "you may take pods from me, but not below this line". ## Voluntary versus involuntary This distinction is the single idea an interviewer is testing. **Voluntary disruptions** are initiated by an actor that *asks* the cluster politely, through the Eviction API: - `kubectl drain` before a node upgrade or repair - cluster-autoscaler removing an underused node - node-pool upgrades in managed Kubernetes - descheduler-style rebalancing tools **Involuntary disruptions** are events nobody asked for and nothing can veto: - node hardware failure, kernel panic, network partition - the cloud provider reclaiming a spot/preemptible instance - **kubelet node-pressure eviction** under memory or disk pressure — the kubelet kills pods locally and never consults the API server's disruption controller - **scheduler preemption** of a lower-priority pod to make room for a higher-priority one - someone running `kubectl delete pod`, which deletes directly rather than evicting PDBs bind only the first list. Saying "a PDB protects my service from node failure" is the classic wrong answer; the protection against node failure is having enough replicas spread across enough nodes and zones. ## The object ```yaml apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: api spec: minAvailable: 80% selector: matchLabels: app: api ``` Key points about the shape: - The **selector is independent of any controller**. A PDB is not "attached" to a Deployment; it matches pods by label. Two Deployments sharing a label are covered by one budget, which is usually a bug — and a pod matched by two PDBs cannot be evicted at all, because that is treated as an error condition. - Exactly one of `minAvailable` / `maxUnavailable` may be set. - `spec.unhealthyPodEvictionPolicy` (GA in Kubernetes 1.31) chooses whether pods that are *running but not Ready* may be evicted even when the budget is exhausted: `IfHealthyBudget` (the default, conservative) or `AlwaysAllow`, which prevents the deadlock where broken pods can never be cleared off a node. ## "Healthy" means Ready The controller counts a pod toward `currentHealthy` only when its `Ready` condition is true. That has a practical consequence: a workload whose pods are failing readiness has `currentHealthy` below `desiredHealthy`, so `disruptionsAllowed` is 0 and every eviction is refused. A broken application therefore blocks node maintenance — often the real story behind a drain that will not finish. ## Reading its state ``` kubectl get pdb api NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE api 80% N/A 2 31d ``` `ALLOWED DISRUPTIONS` (`status.disruptionsAllowed`) is the live budget: how many pods may be evicted right now. Zero means the next drain will stall. `status.expectedPods` comes from the owning controller's replica count via its `scale` subresource, which is why a PDB over bare pods with a percentage target may be unable to compute anything. ## What a good answer includes - PDBs are enforced at eviction time by the API server, not by the scheduler and not by kubelet. - They express *availability during maintenance*, not durability. - They are a contract in both directions: too loose and upgrades cause outages; too strict and the platform team cannot patch nodes. A PDB that permanently allows zero disruptions is not "safe", it is an operational blocker that someone will eventually delete under time pressure. - Every replicated, availability-sensitive workload should have one; single-replica workloads need a deliberate decision, because `minAvailable: 1` on one replica blocks drains forever.