Replicas improve availability only when their failure domains, traffic path, dependencies, and application state permit independent service. Three replicas on one node or in one zone can still fail together.
Quick answer
The scheduler places Pods according to resources and placement constraints. Topology spread and anti-affinity can reduce correlated failure, while taints and tolerations control eligible nodes. A PodDisruptionBudget limits voluntary disruptions against current availability; it does not stop node loss, application crashes, direct deletion, or dependency failure, and it does not guarantee end-to-end service availability.
Learning objectives
- Design placement and disruption policy around explicit node and zone failure domains.
- Interpret Pending, eviction, skew, and PDB evidence without overstating what Kubernetes can preserve.
Prerequisites
Review Kubernetes Resource Requests and Limits and Bulkhead Pattern and Resource Isolation. Browse the course and topic.
Placement and disruption contracts
Resource requests must fit eligible nodes before topology policy matters. Hard affinity rules can make a workload unschedulable; soft preferences can accept imperfect placement. Topology spread constraints make the desired skew explicit across domains such as hostname or zone, but labels must accurately represent those domains.
A PDB protects a minimum available count or maximum unavailable count during eviction-aware voluntary operations. It can slow node drains, which is the intended trade-off. It cannot make unhealthy Pods available, protect against every infrastructure failure, or create database redundancy.
Production failure scenario
The order service has four replicas and a minAvailable: 3 PDB. All four land in one zone because the workload has no spread constraint. A zone failure removes every replica. The PDB never participates because the outage is involuntary.
Restore service through the approved infrastructure path, inspect topology and dependency impact, then add tested placement policy. Verify that replicas actually distribute and that the database, ingress, and identity dependencies survive the same failure domain. The PDB was not broken; it was never the relevant control.
Common misconceptions
- Replica count alone does not express failure-domain diversity.
- A PDB does not prevent involuntary disruption or guarantee availability.
- Required anti-affinity can block scheduling when topology is constrained.
- Tolerating a taint does not force placement on that node.
- A healthy multi-zone application can still depend on a single-zone database or gateway.
Decision checklist
- Name the node, zone, cluster, network, identity, and data failure domains.
- Set accurate resource requests before diagnosing scheduler capacity.
- Use topology spread or affinity deliberately and test degraded placement.
- Choose PDB policy that balances service protection with safe maintenance.
- Monitor Pending reasons, domain skew, eviction delay, and real service SLIs.
- Exercise failure and maintenance procedures without claiming PDB coverage beyond voluntary disruption.
Continue with Kubernetes Horizontal Pod Autoscaling for Backend Services.
Related reading
- Kubernetes Resource Requests, Limits, and JVM Containers
- Kubernetes Rolling Updates and Safe Backend Releases
- Designing Resilient Microservices
Official sources
- Kubernetes scheduling and eviction, accessed August 18, 2026.
- Kubernetes topology spread constraints, accessed August 18, 2026.
- Kubernetes Pod disruptions, accessed August 18, 2026.