100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
DevOps

Pod Disruption Budget

Kubernetes availability guarantee resource

AdvancedConcept4.1K learners

A Pod Disruption Budget (PDB) is a Kubernetes resource that limits how many pods of a replicated application can be voluntarily taken down at the same time, protecting availability during maintenance operations like node drains or upgrades.

Definition

A Pod Disruption Budget (PDB) is a Kubernetes resource that limits how many pods of a replicated application can be voluntarily taken down at the same time, protecting availability during maintenance operations like node drains or upgrades.

Overview

Kubernetes distinguishes between involuntary disruptions — a node crashing, a hardware failure — and voluntary disruptions, which are actions initiated by cluster operators or automated processes, such as draining a node for maintenance, upgrading a cluster, or a cluster autoscaler removing an underused node. A Pod Disruption Budget exists specifically to constrain voluntary disruptions, ensuring that operations like these don't take down more replicas of an application than it can tolerate while staying available. A PDB is defined per application, typically matching a Deployment or StatefulSet's pods via a label selector, and specifies either `minAvailable` (the minimum number or percentage of pods that must remain running) or `maxUnavailable` (the maximum number or percentage that can be disrupted at once). When Kubernetes performs a voluntary disruption — for example, when `kubectl drain` is used to safely evict pods from a node before maintenance — the eviction API checks the relevant PDBs and blocks any eviction that would violate the budget, waiting until it becomes safe. PDBs matter most for stateful or quorum-based systems, where losing too many replicas simultaneously can cause real outages rather than just reduced capacity — a three-node etcd or Kafka cluster, for instance, cannot tolerate more than one node being down at once without losing quorum or replication guarantees. For simple stateless web services, a PDB mainly smooths out rolling maintenance so that capacity doesn't dip below what's needed to serve traffic. PDBs work in coordination with the cluster autoscaler and node draining tooling: when scaling down a node, the autoscaler respects PDBs and will not evict pods in a way that would violate them, sometimes delaying scale-down until it can find a safe path.

Key Concepts

  • Limits voluntary pod disruptions during maintenance and node drains
  • Defined via minAvailable or maxUnavailable thresholds
  • Matches pods through label selectors, typically tied to a Deployment
  • Enforced by the Kubernetes eviction API during drains and autoscaling
  • Does not protect against involuntary disruptions like node crashes
  • Especially important for quorum-based systems like etcd or Kafka
  • Respected by the cluster autoscaler when scaling down nodes

Use Cases

Protecting a stateful database's quorum during node maintenance
Ensuring minimum web service capacity during rolling node upgrades
Coordinating safe cluster autoscaler scale-down operations
Preventing simultaneous eviction of all replicas of a critical service
Supporting zero-downtime cluster upgrades

Frequently Asked Questions