Replica count becomes availability only when placement, eviction, readiness, and spare capacity describe the same failure model.
Zone Spread + Disruption Budget
Availability requires placement and disruption policy to describe the same failure domain.
apiVersion: apps/v1
kind: Deployment
metadata: { name: checkout }
spec:
replicas: 3
template:
metadata: { labels: { app: checkout } }
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector: { matchLabels: { app: checkout } }
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata: { name: checkout }
spec:
minAvailable: 2
selector: { matchLabels: { app: checkout } }Invariant: A voluntary disruption cannot reduce ready capacity below two replicas, and replicas remain spread across zones when capacity exists.
Use when: A replicated Kubernetes workload must tolerate a planned node drain without concentrating every replica in one zone.
Why this boundary matters
Replicas concentrated in one zone share a fate, while a PDB without spare cross-zone capacity can block maintenance without improving recovery.
Failure policy
| Boundary | Action |
|---|---|
| Zone has capacity | Schedule while keeping maxSkew at one |
| Safe placement is unavailable | Keep the Pod pending rather than concentrate risk |
| Eviction preserves minAvailable | Allow voluntary maintenance |
| Eviction crosses the budget | Block and restore capacity first |
| Zone fails involuntarily | Recover through replicas and spare capacity; the PDB cannot prevent failure |
Trade-offs
Strict spread protects a declared failure domain but can block scheduling and rollouts. A PDB protects voluntary eviction only and can stall maintenance when capacity or readiness is already unhealthy.
Decision rule: Use strict placement only for failure domains the cluster is provisioned to survive, then test drain, rollout, and zone-loss scenarios together.
Further reference
Browse all engineering snippets · Read the architecture guide