Pod Disruption Budgets: Stop Upgrades From Killing Your App

Why it exists

Kubernetes often needs to move pods for maintenance, like upgrading a node's software or decommissioning a machine. Without a safeguard, these "voluntary disruptions" could accidentally take down all pods of a replicated application at once, causing an outage. PDBs were created to prevent this self-inflicted downtime by ensuring a minimum number of pods are always running.

The mental model

Think of a PDB as a service level agreement (SLA) you define for your own application, which Kubernetes must honor. You're telling the cluster administrator and their automation, "You are free to perform maintenance, but you are not allowed to reduce my application's running replica count below this line." It turns availability from a hopeful side effect into a declared, machine-checked requirement.

How it works

You create a PDB resource as a YAML object. In it, you use a label selector to specify which pods it applies to (e.g., all pods with app: my-api). Then you define the budget using either minAvailable (an integer or percentage of pods that must remain) or maxUnavailable (an integer or percentage of pods that can be taken down). When a voluntary disruption occurs, like a node drain, the Kubernetes API server checks if evicting a pod would violate the PDB. If it would, the eviction is rejected until it's safe to proceed.

When to use it

Use PDBs for any production application where high availability is important, especially for stateless services like web servers or APIs running with multiple replicas. They are a core tool for building resilient systems that can survive routine cluster maintenance without impacting users.

When not to use it

Be careful with single-replica applications. Setting a PDB with minAvailable: 1 or maxUnavailable: 0 on a single-pod app will block any node drain, halting cluster maintenance indefinitely. Also, remember PDBs do not help with involuntary disruptions like a node crash, a power outage, or network failure. For that, you need proper replica counts and multi-zone deployments. PDBs are for planned, graceful terminations only.

One canonical example

An API server runs with 5 replicas. The team creates a PDB with minAvailable: 3 for that deployment. A cluster admin drains a node for a kernel upgrade. This node is running 2 of the API server pods. The drain command successfully evicts the first pod. When it tries to evict the second, the API server sees this would leave only 3 pods running (5 total - 1 already evicted - 1 to be evicted = 3). Since 3 is the minAvailable value, the eviction is blocked until another pod for that service starts up on a different node, bringing the available count back up.