What is a Pod Disruption Budget (PDB) in Kubernetes?

You try to drain a node for maintenance. It hangs. You wait 20 minutes. Nothing. Something is blocking it.

Nine times out of ten, the culprit is a Pod Disruption Budget (PDB). Here's what it is and how to use it correctly.

The Problem PDB Solves

Kubernetes can evict pods in several situations:

• Node drain (kubectl drain)
• Node upgrade
• Cluster autoscaler scaling down
• Preemption for higher-priority pods

Without a PDB, Kubernetes could evict all replicas of a deployment simultaneously. If your app has 3 replicas and all 3 get evicted at once, you have an outage.

A PDB tells Kubernetes: "You can disrupt this app, but always keep at least N pods running."

PDB Basics

A PDB has two settings — you use one or the other:

minAvailable — Minimum number of pods that must be running during disruption.

maxUnavailable — Maximum number of pods that can be unavailable during disruption.

# Using minAvailable — keep at least 2 pods running
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
  namespace: production
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

# Using maxUnavailable — allow at most 1 pod to be down
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
  namespace: production
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: my-app

You can also use percentages:

spec:
  minAvailable: "80%"    # Keep 80% of pods running
  # or
  maxUnavailable: "20%"  # Allow 20% to be unavailable

How PDB Affects Node Drain

When you run kubectl drain node-1:

1. Kubernetes tries to evict pods from node-1 one by one
2. For each pod, it checks if evicting it would violate any PDB
3. If eviction would violate PDB → it blocks and waits
4. Once other pods are rescheduled and running elsewhere → eviction is allowed

kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data
 
# If blocked, you'll see:
# error when evicting pods/"my-app-abc-123" -n "production" (will retry after 5s):
# Cannot evict pod as it would violate the pod's disruption budget.

The drain will retry every 5 seconds. It's not stuck — it's waiting for pods to be rescheduled on other nodes.

PDB Example: 3-Replica Deployment

# Deployment: 3 replicas
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-api
spec:
  replicas: 3
  # ...
 
---
# PDB: always keep at least 2 running
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: payment-api-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: payment-api

During a node drain:

• Pod 1 evicted → 2 remaining (meets minAvailable: 2 ✅)
• Wait for Pod 1 to reschedule elsewhere
• Pod 2 evicted → 2 remaining again ✅
• And so on

The Mistake That Blocks Node Drain Forever

Problem: PDB with minAvailable: 1 on a Deployment with replicas: 1.

# This will BLOCK forever
apiVersion: policy/v1
kind: PodDisruptionBudget
spec:
  minAvailable: 1    # Must have 1 pod running
  selector:
    matchLabels:
      app: single-replica-app
 
# Deployment has only 1 replica
# To evict it, you'd need 0 pods, but PDB requires 1
# Impossible to satisfy — node drain hangs

Fix options:

1. Scale the deployment to 2+ replicas before draining
2. Delete the PDB temporarily
3. Use --force on drain (not recommended for production)
4. Fix the PDB: minAvailable: 0 if single-replica is acceptable

Check Current PDBs

# List all PDBs
kubectl get pdb -A
 
# Check PDB status (shows current disruption counts)
kubectl get pdb -n production -o wide
# NAME             MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
# payment-api-pdb  2               N/A               1                     5d
 
# "ALLOWED DISRUPTIONS: 1" means you can evict 1 pod right now
# "ALLOWED DISRUPTIONS: 0" means a drain will block
 
# Describe a PDB
kubectl describe pdb payment-api-pdb -n production

PDB for Different App Types

Stateless API (3 replicas):

spec:
  maxUnavailable: 1    # Allow 1 of 3 to be evicted at a time

Database (2 replicas, never both down):

spec:
  minAvailable: 1    # Always keep at least 1 running

Kafka/Zookeeper (needs quorum):

# 3-node Kafka: need at least 2 for quorum
spec:
  minAvailable: 2

Single-replica dev/staging app:

spec:
  maxUnavailable: 1    # Allow the one pod to be evicted
  # or just don't create a PDB for non-critical apps

When to NOT Use a PDB

• Single-replica pods with no HA requirement
• Dev/staging namespaces where downtime is acceptable
• Jobs or CronJobs (they're not long-running services)
• DaemonSets (they have their own eviction handling)

Summary

PDB is the right way to protect your services during maintenance — but remember that a PDB with impossible constraints will block node operations indefinitely.

For CKA exam prep and Kubernetes hands-on labs, KodeKloud covers PDBs, node management, and cluster maintenance in depth.