What Is a Pod Disruption Budget?

Pod Disruption Budget is a Kubernetes resource that limits the number of pods from a given application that can be voluntarily disrupted at the same time. Voluntary disruptions include node drains, cluster upgrades, and autoscaler node removal. PDBs ensure that a minimum number of pods remain available during these operations, protecting application availability during planned maintenance.

Why Pod Disruption Budgets Matter

During cluster upgrades, node maintenance, or autoscaler scale-down events, Kubernetes needs to evict pods from nodes. Without PDBs, Kubernetes might evict too many pods from the same application simultaneously, causing downtime. PDBs tell Kubernetes how many pods can be safely disrupted at once, ensuring the application maintains enough healthy replicas to continue serving traffic.

For production services with strict availability requirements, PDBs are a critical safeguard. They prevent well-intentioned operations like cluster upgrades from accidentally causing outages. Combined with proper replica counts and health checks, PDBs form an important layer of production readiness that ensures applications remain available during all planned infrastructure changes.

How Pod Disruption Budgets Work

You create a PDB that specifies either a minimum number of available pods or a maximum number of unavailable pods, along with a label selector identifying which pods the budget applies to. When Kubernetes attempts a voluntary disruption, it checks all applicable PDBs before evicting any pod. If evicting the pod would violate the budget, Kubernetes blocks the disruption and retries later. This does not protect against involuntary disruptions like node crashes.

Understanding how pod disruption budget fits into the broader cloud-native ecosystem is important for making informed architecture decisions. It works alongside other tools and practices in the DevOps and platform engineering space, and choosing the right combination depends on your team's specific requirements, scale, and operational maturity.

Key Features

Minimum Available

Specify the minimum number of pods that must remain running during voluntary disruptions.

Maximum Unavailable

Alternatively, specify the maximum number of pods that can be unavailable at any time during disruptions.

Graceful Operations

Node drains and cluster upgrades respect PDBs, evicting pods only when the budget allows.

Status Tracking

PDBs report current disruption status, showing how many disruptions are currently allowed.

Common Use Cases

Ensuring at least two replicas of a critical API remain available during node drain operations.

Protecting stateful applications from losing quorum during rolling cluster upgrades.

Preventing the cluster autoscaler from removing too many nodes at once and disrupting application availability.

Setting maximum unavailable to one for a three-replica deployment to guarantee two pods serve traffic during maintenance.

How Obsium Helps

Obsium's Kubernetes consulting team helps organizations implement and optimize pod disruption budget as part of production-grade infrastructure. Whether you are adopting pod disruption budget for the first time or looking to improve an existing implementation, our engineers bring hands-on experience across cloud platforms and Kubernetes environments. Learn more about our Kubernetes consulting services →