PodDisruptionBudget ā Extended Technical Detail
What is a PodDisruptionBudget in Simple Terms?
When you drain a node for maintenance, Kubernetes starts evicting pods. Without a PodDisruptionBudget (PDB), it could evict ALL pods of your payments service simultaneously ā causing a full outage. A PDB tells Kubernetes: "Never take down more than 1 pod at a time. Always keep at least 2 running."
Voluntary vs Involuntary Disruptions
+------------------------------------------+ +------------------------------------------+| Voluntary Disruptions | | Involuntary Disruptions || (PDB PROTECTS against these) | | (PDB CANNOT protect against these) || | | || * kubectl drain node | | * Node hardware failure || * Cluster version upgrades | | * Out-of-memory kernel kill || * Node autoscaling (scale down) | | * Network partition || * Manual pod eviction via API | | * Cloud provider AZ outage |+------------------------------------------+ +------------------------------------------+How a PDB Works During a Node Drain
+------------------------------------------+| Zerodha: 5 trading-api pods across nodes | <- minAvailable: 4 is set in PDB+------------------------------------------+ | v+------------------------------------------+| kubectl drain mumbai-worker-2 | <- Operator runs maintenance drain+------------------------------------------+ | v+------------------------------------------+| Evict pod-1 (4 remaining) ALLOWED | <- PDB check: 4 >= minAvailable(4), OK+------------------------------------------+ | v+------------------------------------------+| Evict pod-2 (3 remaining) BLOCKED | <- PDB check: 3 < minAvailable(4), DENIED| Kubernetes waits for pod-1 to reschedule | Drain pauses here automatically+------------------------------------------+ | v+------------------------------------------+| pod-1 rescheduled on worker-3 (5 again) || Evict pod-2 now ALLOWED (4 remaining) | <- PDB allows eviction to resume+------------------------------------------+Example PodDisruptionBudget
1# pdb.yaml ā protect the trading API from mass evictions during drain2apiVersion: policy/v13kind: PodDisruptionBudget4metadata:5 name: trading-api-pdb6 namespace: production7spec:8 minAvailable: 4 # Always keep at least 4 pods running9 selector:10 matchLabels:11 app: trading-api # Targets pods with this labelminAvailable vs maxUnavailable
+---------------------------+ +---------------------------+| minAvailable: 4 | | maxUnavailable: 1 || | | || Absolute guarantee: | | Relative disruption cap: || at least 4 pods must be | <------> | at most 1 pod can be down || Running at all times | | at any given time || | | || Good for: fixed SLA pods | | Good for: scaling apps || (trading, payments) | | where replica count grows |+---------------------------+ +---------------------------+1# Alternative ā cap disruptions as a percentage2spec:3 maxUnavailable: "20%" # At most 20% of pods can be down simultaneously4 selector:5 matchLabels:6 app: trading-apiPercentage-Based PDB for Auto-Scaling Services
For Hotstar-style services where replica count spikes during IPL, percentage-based PDBs scale with the deployment:
1apiVersion: policy/v12kind: PodDisruptionBudget3metadata:4 name: stream-api-pdb5 namespace: streaming-prod6spec:7 minAvailable: "80%" # Always keep 80% of pods running regardless of replica count8 selector:9 matchLabels:10 app: stream-apiChecking PDB Status
1# List all PDBs in a namespace2kubectl get pdb -n production3 4# NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE5# trading-api-pdb 4 N/A 1 12d6 7# ALLOWED DISRUPTIONS = current replicas - minAvailable8# If this is 0, the cluster CANNOT evict any pod from this deployment right now9 10# Describe for full details11kubectl describe pdb trading-api-pdb -n production12 13# Check if a drain is being blocked by a PDB14kubectl drain mumbai-worker-2 --ignore-daemonsets --delete-emptydir-data15# If blocked, output shows: Cannot evict pod as it would violate the pod's disruption budgetTroubleshooting Common PDB Problems
| Problem | Symptom | Fix |
|---|---|---|
| Node drain stuck forever | drain command hangs, never completes |
PDB ALLOWED DISRUPTIONS is 0 ā a pod is not healthy enough to allow eviction. Fix the unhealthy pod first |
| PDB blocks cluster upgrade | Upgrade stalls on a node | Check if minAvailable equals replica count ā reduce minAvailable by 1 temporarily |
| PDB not protecting pods | All pods evicted despite PDB | Selector matchLabels doesn't match pod labels ā verify with kubectl get pods -l app=trading-api |
| Disruption budget confusing value | ALLOWED DISRUPTIONS shows 0 unexpectedly | One or more pods in the selector are not in Running state ā PDB won't allow disruptions when replicas are already below threshold |
| PDB set on single-replica pod | Drain is permanently blocked | Never set minAvailable: 1 on a Deployment with only 1 replica ā scale to 2 first, then drain |
š Remember: PDBs only protect against voluntary disruptions ā planned maintenance, node drains, cluster upgrades. They cannot prevent involuntary disruptions like a node crashing due to hardware failure or a kernel OOM kill.
š” Tip: Always pair a PDB with a Deployment that hasreplicas >= minAvailable + 1. If you setminAvailable: 5but only have 5 replicas,ALLOWED DISRUPTIONSwill be 0 and no node can ever be drained. The safe formula is:replicas = minAvailable + number_of_nodes_you_drain_at_once.
ā ļø Security: A PDB withminAvailable: 1on a payment processing pod means 99% of pods could be evicted simultaneously during a hostile API call to the eviction endpoint. Always combine PDBs with RBAC restrictions onpods/evictionfor sensitive workloads.
š“ Common Mistake: SettingminAvailableequal to the total replica count (e.g.,minAvailable: 5with 5 replicas). This setsALLOWED DISRUPTIONSto 0 permanently ā the cluster can never drain any node, blocking all future upgrades, maintenance, and autoscaler scale-downs.