Disruption Budgets, Topology Spread & Priority

In one line

Replicas only protect you if they don't all die together. PodDisruptionBudgets limit voluntary evictions, topology spread keeps replicas across zones and nodes, and priority classes decide who gets evicted when resources run out.

0/5 · 0%

Think of it like this

A hospital's staffing rules. Never let more than one surgeon go on break at a time (PDB), spread nurses across all wards rather than one (topology spread), and in an emergency, admin staff give up their desks before ICU nurses do (priority).

Key ideas

01
VOLUNTARY vs INVOLUNTARY disruptions: node drains for upgrades, autoscaler scale-downs, and Karpenter consolidation are voluntary and respect PDBs; node crashes and zone outages are involuntary and don't. A PODDISRUPTIONBUDGET (minAvailable: 2 or maxUnavailable: 1) makes the eviction API refuse to evict more pods than allowed, so drains wait instead of taking your service down.
02
Pitfalls: a PDB with maxUnavailable: 0 or minAvailable equal to replicas blocks every drain forever (upgrades stall); single-replica deployments can't satisfy a PDB and still have downtime on drains, so run at least 2 replicas for anything user-facing.
03
TOPOLOGY SPREAD CONSTRAINTS spread replicas across topology.kubernetes.io/zone and kubernetes.io/hostname with a maxSkew. Without them, the scheduler may put all replicas on one node or zone, so one failure takes them all out. (Pod anti-affinity does something similar but is coarser: Phase 4.)
04
PRIORITYCLASSES rank pods: when a node is out of resources, the scheduler can PREEMPT lower-priority pods to place higher-priority ones. Give critical system and customer-facing workloads higher priority than batch jobs; combine with QoS classes (Guaranteed pods are evicted last under node memory pressure: Phase 4).

Code & diagrams

PDB + spread + priority for a critical serviceyaml

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: { name: checkout }
spec:
  maxUnavailable: 1
  selector: { matchLabels: { app: checkout } }
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata: { name: customer-critical }
value: 100000
description: Customer-facing request path
---
# in the Deployment's pod spec:
#   priorityClassName: customer-critical
#   topologySpreadConstraints:
#     - maxSkew: 1
#       topologyKey: topology.kubernetes.io/zone
#       whenUnsatisfiable: DoNotSchedule
#       labelSelector: { matchLabels: { app: checkout } }
#     - maxSkew: 1
#       topologyKey: kubernetes.io/hostname
#       whenUnsatisfiable: ScheduleAnyway
#       labelSelector: { matchLabels: { app: checkout } }

Explain it without notes

A cluster upgrade is stuck because a node won't drain. What's the likely cause?

Practice

Design the resilience settings for a 3-replica API in a 3-zone cluster.

Trade-offs

↔
Strict spread and PDBs improve availability but can block scheduling or drains when capacity is tight; ScheduleAnyway and sensible budgets balance safety with operability.

Done when you can

Every multi-replica service has a PDB and zone spread
I know which disruptions PDBs do and don't protect against