Kubernetes Resilience Does Not Begin with Replica Count
Running three replicas is often treated as sufficient evidence that a Kubernetes workload is highly available. It is not. Replicas can share a node, a zone, a dependency, or a maintenance window.
Resilience comes from aligning placement, disruption control, capacity, and traffic behavior with explicit failure domains. These decisions need a supported platform contract, not optional annotations copied between teams.
What matters
- Failure-domain placement: Spread replicas across the node and zone boundaries the architecture claims to tolerate.
- Schedulable recovery: Reserve enough capacity for replacement pods after a node or zone becomes unavailable.
- Controlled maintenance: Use disruption budgets to constrain voluntary evictions, while recognizing that they do not prevent infrastructure failure.
- Honest health signals: Readiness must remove degraded instances before traffic turns redundancy into correlated failure.
- Consistent traffic behavior: Routing should preserve availability without silently concentrating load in a surviving domain.
Recommendation
Define availability classes as platform standards. Each class should combine replica expectations, topology rules, disruption policy, capacity assumptions, and operational ownership.
Teams should select a supported resilience class rather than assemble independent safeguards. Replica count is an input. The real architecture is the agreement about which failures the system can absorb and how it recovers.