A PodDisruptionBudget (PDB) limits how many matching Pods can be unavailable during voluntary evictions that use the Kubernetes Eviction API. It does not stop a node crash, prevent a deployment from being deleted, or create replacement capacity. Its selector must match the intended workload; a healthy-looking budget attached to zero Pods provides no protection.
Pod disruption budgets: make node drains measurable
Operational decision
A document API runs four replicas and needs three ready during one-node maintenance. Set minAvailable to three, inspect currentHealthy and disruptionsAllowed, and verify replacement Pods can schedule before draining. The manifest is a starting policy for a single namespace. Check that the Deployment template carries the same app label and that the replicas span nodes. If the budget blocks a drain, diagnose unavailable replicas, capacity, and readiness first. Using a forceful deletion to finish a maintenance window bypasses the availability contract. A PDB also does not guarantee zero user errors; validate the client path while a replica leaves service.
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: {name: document-api-budget, namespace: documents}
spec:
minAvailable: 3
selector:
matchLabels: {app: document-api}Cost and verification
A strict budget can delay node replacement indefinitely when a workload is already unhealthy or spare capacity is missing. Four replicas cost more than one, but the extra instance permits a controlled eviction while maintaining the three-instance floor. Track drain duration and rejected evictions alongside availability; a successful policy is one operators can exercise without bypassing it. Budget health depends on readiness probes, so a false positive readiness check can make the protection misleading.
Common Mistakes
- Do not assume a PDB protects against node failure.
- Do not set a three-Pod minimum on three replicas and expect an immediate drain.
- Do not bypass the Eviction API to hide an unhealthy workload.
Connected lessons
- DevOps: delivery, infrastructure, and reliable operations
- Kubernetes Deployment: rolling update capacity
- Kubernetes probes: startup, readiness, and liveness
- Capacity and load tests: identify the next bottleneck
