MeteorOps | DevOps Dictionary | Pod Disruption Budget (PDB)

Pod Disruption Budget (PDB)

Pod Disruption Budget (PDB) is a Kubernetes policy that limits how many matching pods can be voluntarily evicted at the same time. It helps keep enough replicas running during planned operations such as node drains, cluster upgrades, and autoscaler scale-down events.

What a Pod Disruption Budget does

A PDB protects application availability during controlled Kubernetes maintenance. It tells Kubernetes the minimum level of availability your workload needs before pods can be evicted.

Common voluntary disruptions include:

Running kubectl drain on a node
Managed Kubernetes node pool upgrades
Cluster autoscaler removing underused nodes
Evictions requested through the Kubernetes Eviction API

A PDB does not stop involuntary disruptions such as node crashes, kernel panics, hardware failures, or pods being killed because the node runs out of resources.

How it works

A PDB uses a label selector to match a group of pods, usually pods managed by a Deployment, StatefulSet, or similar controller. Kubernetes then calculates whether evicting a pod would violate the budget.

You define availability with one of two fields:

minAvailable: the minimum number or percentage of pods that must remain available.
maxUnavailable: the maximum number or percentage of pods that may be unavailable.

For example, if a service runs 3 replicas and has maxUnavailable: 1, Kubernetes allows only one voluntary eviction at a time. The next eviction must wait until enough pods are ready again.

Example

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: api

This PDB applies to pods with the label app: api. If the workload has multiple replicas, Kubernetes will allow at most one matching pod to be unavailable due to voluntary eviction.

Common use cases

Protecting stateless services: keep enough API, web, or worker replicas available during node maintenance.
Safer cluster upgrades: reduce the chance that managed node upgrades take down too many replicas at once.
Stateful workloads: prevent multiple database, queue, or coordination service pods from being evicted together.
Autoscaling guardrails: stop cluster autoscaler actions that would break minimum availability rules.

Important limitations

A PDB cannot protect a single-replica workload from downtime during eviction. If one pod is all you have, Kubernetes has no spare replica to keep available.
A strict PDB can block node drains and slow cluster upgrades if there are not enough healthy replicas.
A PDB depends on pod readiness. Misconfigured readiness probes can make Kubernetes think pods are unavailable.
A PDB does not replace proper replica counts, anti-affinity, topology spread constraints, resource requests, or application-level failover.

PDB vs replica count

A replica count says how many pod instances Kubernetes should run. A PDB says how many of those pods must remain available during voluntary disruption.

For example, a Deployment with replicas: 3 creates three pods. A PDB with minAvailable: 2 tells Kubernetes to avoid voluntary actions that would leave fewer than two ready pods.

Practical guidance

Use PDBs for production workloads with two or more replicas.
Prefer maxUnavailable: 1 for many stateless services with 3 or more replicas.
Use minAvailable when you know the exact number of pods required to serve traffic safely.
Test node drains in staging to catch PDBs that block maintenance.
Pair PDBs with readiness probes so Kubernetes makes eviction decisions based on real service availability.

DevOps Dictionary