Description
If several Deployment Pods are voluntarily evicted during operations such as node draining, availability can drop despite having replicas. A PodDisruptionBudget (PDB) constrains disruptions performed through the Eviction API.
A PDB does not prevent node failures or direct Pod deletion, and it does not constrain Deployment rolling updates. Configure update strategy and failure-domain distribution separately.
Potential impact
- Too few available replicas during maintenance can cause latency or an outage.
- Overly restrictive budgets can block node drains or maintenance.
Remediation
- Define a PDB in the same namespace that selects the actual Deployment Pods, and set either minAvailable or maxUnavailable according to availability needs.
- Check readiness, replica count and replacement capacity, and test draining. Review Deployment rolling updates and Pod distribution separately.
Examples
Replace the historical image with a maintained, verified version. This example limits voluntary evictions so at least two of the three replicas remain available.
Before
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
A Deployment is shown without a PDB for voluntary evictions. Check existing policies in the same namespace as well.
After
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: nginx-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
A PDB selecting app=nginx Pods specifies minAvailable: 2. This does not guarantee minimum availability against every failure or direct deletion.