A disruption budget protects availability only when readiness is meaningful, replicas are sufficient, and pods are spread across failure domains.
Kubernetes Disruption Budget
Voluntary maintenance must consume an explicit availability budget.
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: api
spec:
minAvailable: 2
selector:
matchLabels:
app: api
# Requires at least 3 replicas; pair with readiness and topology spread.Invariant: Voluntary disruption never removes more healthy replicas than the service can tolerate.
Use when: Voluntary maintenance must preserve service capacity.
Why this boundary matters
Replica count alone does not constrain voluntary eviction. A disruption budget tells maintenance when removal would cross minimum serving capacity.
Failure policy
| Boundary | Action |
|---|---|
| Eviction preserves the budget | Allow voluntary disruption |
| Eviction would violate the budget | Block and retry maintenance later |
| Node or zone fails involuntarily | Recover through replicas and topology; the PDB cannot prevent it |
| Readiness is false | Do not count the pod as available capacity |
| Single replica workload | Choose explicitly between maintenance and availability |
Trade-offs
A strict PDB protects capacity but can block node drains, upgrades, and autoscaling. A permissive budget improves operability but may allow maintenance to remove too much capacity.
Decision rule: Set the budget from measured minimum serving capacity and test that routine maintenance can still make progress.
Further reference
Browse all engineering snippets · Read about capacity governance