Deployment with Pod Disruption Budget

Pod Disruption Budgets

A PodDisruptionBudget (PDB) limits how many pods can be unavailable during voluntary disruptions (node drain, cluster upgrade, scaling down). This is critical for maintaining availability in production.

Deployment Configuration

apiVersion: apps/v1
kind: Deployment
metadata:
  name: critical-api
  labels:
    app: "critical-api"
spec:
  replicas: 4
  template:
    spec:
      containers:
        - name: api
          image: my-api:latest
          ports:
            - name: http
              containerPort: 8080
          resources:
            requests:
              cpu: "200m"
              memory: "256Mi"
            limits:
              cpu: "1000m"
              memory: "512Mi"
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

PDB Configuration (separate resource)

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: critical-api-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: "critical-api"

minAvailable vs maxUnavailable

Setting	Example	Meaning
minAvailable: 2	4 replicas	At least 2 must be running; up to 2 can be disrupted
maxUnavailable: 1	4 replicas	At most 1 can be unavailable; 3 must be running
minAvailable: "50%"	4 replicas	At least 50% (2) must be running

How PDBs Work

When a cluster operator runs kubectl drain node-1:

1. Kubernetes checks all PDBs that match pods on that node
2. If evicting a pod would violate its PDB, the drain is blocked
3. The operator must wait or use --force to override (not recommended)
4. Drain proceeds one pod at a time, respecting all PDBs

Best Practices

• Every production Deployment with >= 2 replicas should have a PDB
• maxUnavailable: 1 is a safe default for most services
• PDBs only protect against voluntary disruptions (drain, upgrade), not involuntary ones (node crash, OOM kill)
• Ensure your replicas can handle the load even at minimum availability