What is a Kubernetes PodDisruptionBudget?
Learn what a Kubernetes PodDisruptionBudget does, minAvailable vs maxUnavailable, and how it protects services during node drains.
Expected Interview Answer
A PodDisruptionBudget (PDB) is a Kubernetes object that limits how many replicas of an application can be voluntarily taken down at the same time during actions like node drains or cluster upgrades, protecting availability during planned disruptions.
A PDB targets a set of Pods via a label selector and declares either minAvailable (the minimum number or percentage of Pods that must stay running) or maxUnavailable (the maximum number or percentage allowed to be down at once). It only governs voluntary disruptions initiated through the Eviction API, such as kubectl drain, cluster-autoscaler scale-down, or node maintenance tooling; it does nothing for involuntary disruptions like a node crashing or an out-of-memory kill. When an eviction request would violate the budget, the API server rejects that specific eviction and the calling tool must retry later or move on to a different Pod. This lets platform teams safely drain nodes for maintenance without a rolling operation ever pushing a stateful or low-replica service below its safe minimum.
- Protects service availability during voluntary cluster maintenance
- Lets node drains and autoscaler scale-downs proceed safely
- Gives explicit control via minAvailable or maxUnavailable
- Applies automatically to any tool using the standard Eviction API
AI Mentor Explanation
A PodDisruptionBudget is like a team rule stating that at least three specialist bowlers must always remain fit and available during a tour, even while the physio rotates players out for rest days. The physio (the maintenance tool) can send one bowler for a scan, but is blocked from resting two more at the same time if that would drop the squad below three fit bowlers. This does not protect against an unexpected injury during a match, only against the physio scheduling too many rest days at once. The team keeps performing on the field while planned rotations happen safely in the background.
Step-by-Step Explanation
Step 1
Define the selector
Target the workload’s Pods with a label selector matching the Deployment or StatefulSet.
Step 2
Set minAvailable or maxUnavailable
Choose one, as an absolute count or a percentage, to declare the safe disruption limit.
Step 3
Apply the PDB
Kubernetes tracks current healthy Pod count against the budget continuously.
Step 4
Eviction requests are checked
kubectl drain or the autoscaler calls the Eviction API; requests violating the budget are rejected and retried later.
What Interviewer Expects
- Understanding that PDBs only cover voluntary disruptions, not crashes
- Knowledge of minAvailable vs maxUnavailable as mutually exclusive options
- Awareness that PDBs block the Eviction API, not direct kubectl delete
- Ability to explain why PDBs matter for safe node drains and upgrades
Common Mistakes
- Believing a PDB prevents Pods from crashing or being OOM-killed
- Setting maxUnavailable to 0 on a single-replica workload, blocking all drains
- Forgetting the selector must match the actual workload’s Pod labels
- Assuming a PDB throttles scaling operations rather than evictions
Best Answer (HR Friendly)
“A PodDisruptionBudget is a safety rule we put on our Kubernetes workloads that says how many instances of a service are allowed to be taken down at once during planned maintenance, like a node upgrade. It means our operations team can safely maintain the cluster without accidentally taking a service fully offline, because Kubernetes will refuse to remove too many instances at the same time.”
Code Example
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: myapp-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: myapp
# Drain a node; evictions honoring the PDB may be retried
kubectl drain node-1 --ignore-daemonsets --delete-emptydir-dataFollow-up Questions
- What is the difference between minAvailable and maxUnavailable?
- Does a PodDisruptionBudget protect against a node crashing unexpectedly?
- What happens when kubectl drain hits a PDB it would violate?
- How would you set a PDB for a single-replica critical workload?
MCQ Practice
1. What type of disruption does a PodDisruptionBudget protect against?
PDBs only govern voluntary disruptions performed through the Eviction API, not involuntary failures like crashes.
2. Which two fields can a PDB use to set its limit?
A PDB declares its safety threshold using either minAvailable or maxUnavailable, but not both at once.
3. What happens when an eviction would violate the PDB?
The API server rejects the eviction request when it would drop availability below the configured budget, so the caller must retry.
Flash Cards
What is a PodDisruptionBudget? — An object limiting how many Pods of a workload can be voluntarily disrupted at once.
What disruptions does a PDB NOT cover? — Involuntary ones, like node crashes or OOM kills.
minAvailable vs maxUnavailable? — Two mutually exclusive ways to express the same safety threshold, as count or percentage.
What API enforces a PDB? — The Kubernetes Eviction API, used by kubectl drain and the cluster autoscaler.