Full lesson
Explore the full explanation, examples, and visuals at your own pace.
Node A stops responding
When Node A fails, Pod A stops serving immediately. Pod B remains on Node B, leaving one available replica. Kubernetes may not know Node A has failed yet, so lost service and detected failure are separate events.
Health reports stop arriving
Node A doesn’t send an instant failure alert. Its kubelet normally renews a Lease and reports node status; when those updates stop, the control plane can infer that Node A may be unhealthy. That evidence takes time to accumulate.
Node A becomes unreachable
After a grace period without health updates, the control plane marks Node A’s Ready condition Unknown. New Pods won’t be scheduled there, but that status change doesn’t immediately remove Pod A’s API record.
Unavailable is not yet replaced
Pod A may still appear in Kubernetes’ API, but that record doesn’t mean it can serve traffic. Node A is unreachable, so Pod B on Node B is the only available Pod here. Kubernetes can’t restart Pod A on a dead machine or move it elsewhere.
Node A is unreachable, but Pod A still appears in the API. Is Pod A serving requests?
Let's think this through. Node A is unreachable, but Pod A still appears in the API. Is Pod A serving requests? A: Yes, because its API record exists. B: No, the failed node cannot run it. C: Yes, Kubernetes moved it to Node B. Choose an answer, or just think it through. I'll explain in a moment.
- Yes, because its API record exists
- No, the failed node cannot run it
- Yes, Kubernetes moved it to Node B
Node A is unreachable, but Pod A still appears in the API. Is Pod A serving requests?
The answer is B: No, the failed node cannot run it. The API record can outlast the running Pod's availability. Kubernetes has not moved Pod A; replacement requires a separate eviction and creation process.
- Yes, because its API record exists
- No, the failed node cannot run it
- Yes, Kubernetes moved it to Node B
Why replacement takes time
Kubernetes detects missing node health first. By default, Pods tolerate an unreachable node for a period before eviction. Then a replacement still needs time to start and become ready.
- Detect missing node health
- Wait through applicable eviction delay
- Start and ready a new Pod
The missing replica is recreated
Once eviction removes Pod A's API object, the ReplicaSet sees only one of its desired two Pods. It creates a distinct new Pod, which then waits for the Scheduler to place it.
Node B now hosts both replicas
Kubernetes restores the desired replica count by creating a replacement, not by moving a Pod off the failed machine. Here, the Scheduler places New Pod beside Pod B on Node B; service recovers only when there’s eligible capacity and the new Pod becomes ready.
Replacement, not migration
Kubernetes replaces managed Pods; it cannot move a failed machine's Pods; placement needs eligible capacity and readiness before service recovers. Eviction and scheduling take time, and the replacement doesn't inherit Pod A's local state.