Your Deployment says replicas: 3. All three pods are Ready. The dashboard is green.
Then one node disappears and so does the application.
Replica count is a desired quantity. Availability is a property you have to test.
Failure mode 1: all replicas share a failure domain
The scheduler is not obligated to distribute every workload across multiple nodes or zones in the way your business expects. Inspect placement rather than assuming it:
kubectl get pods -n production -l app=checkout -o wide
kubectl get nodes -L topology.kubernetes.io/zone
For important stateless workloads, define appropriate topologySpreadConstraints or pod anti-affinity. Consider how constraints behave when a zone has no available nodes: a strict rule improves separation but can also leave replacement pods Pending.
Failure mode 2: your disruption policy blocks maintenance
A PodDisruptionBudget (PDB) governs many voluntary evictions, such as a node drain through the Eviction API. It does not prevent hardware failures, and it does not protect against every possible pod deletion.
A three-replica app with minAvailable: 3 may prevent an ordinary drain because no eviction is allowed. That looks conservative until routine upgrades start failing.
kubectl get pdb -A
kubectl describe pdb checkout -n production
Design the budget around the number of healthy replicas your application can genuinely tolerate losing. Test the maintenance path, not just the steady state.
Failure mode 3: Ready doesn't mean usable
A readiness probe that returns 200 when the process is alive—but before it can serve customer traffic—creates false confidence. A badly scoped liveness probe can make an overloaded service restart repeatedly during a dependency incident.
Probes should represent the behavior they control. Readiness decides whether a pod receives traffic; liveness decides whether it should be restarted. Neither replaces external user-journey monitoring.
Failure mode 4: replicas depend on the same fragile component
Three API pods backed by one database instance, one DNS path, or one external authentication endpoint can fail together. A system is only as available as the dependencies on its critical request path.
A better availability review asks:
- Which node, zone, network, and data-layer failures are in scope?
- Do replicas actually span those boundaries?
- Can an ordinary rollout and node drain finish without customer impact?
- Are there enough spare resources to reschedule after a loss?
- Have we tested the application rather than just the Deployment object?
The detailed mechanics are in my Kubernetes high-availability guide. The important distinction here is simpler: three green pods are evidence of three green pods, not proof of high availability.
Discussion: What's the most surprising single point of failure you've found in a supposedly HA Kubernetes setup?
Need independent eyes on availability and workload configuration? See the Kubernetes Cluster Audit or request a discovery call.