TL;DR: For a lost-heartbeat failure, the kubelet stops reporting, the controller sets Ready=Unknown after the configured heartbeat grace period (50 seconds in the current reference), taints it, and only then does eviction begin after a commonly defaulted toleration period of 300 seconds; inspect the actual pod tolerations. So a hard node failure takes roughly five to six minutes to shed its pods, and the pods keep running on the node the whole time if it is merely unreachable.
How to approach it
Give the timeline with numbers, because the numbers are the answer. Then say what the delay is for, since an interviewer will ask why it is not instant.
A strong answer
The kubelet posts a heartbeat via a Lease object, by default every 10 seconds. The node controller watches those leases and sets Ready=Unknown after the node-monitor grace period, currently documented as 50 seconds by default. That is the first transition and nothing has been evicted yet.
Unknown readiness produces node.kubernetes.io/unreachable:NoExecute; an explicitly unhealthy Ready=False node gets node.kubernetes.io/not-ready:NoExecute. Pods carry a default toleration for that taint with tolerationSeconds: 300, which is why they sit for another five minutes before eviction. Add them up and the budget is explicit: 50 + 300 = 350 seconds, just under six minutes, before eviction becomes eligible. Worth knowing precisely, because a team expecting a lost node to be replaced in under a minute has a six-minute hole in its availability model that no amount of replica count will close if all the replicas were on that node. Replacement also depends on controller behavior, scheduling capacity, storage attachment and startup; this is not a failover deadline.
The important nuance is what is happening on the node during that window. If the node is unreachable but alive, the pods are still running and still serving. The control plane cannot tell the difference between a dead node and a partitioned one, and it deliberately errs toward not evicting, because evicting from a healthy-but-partitioned node gives you two copies of a workload that was meant to be singular. Even Deployment replicas can duplicate external work; for a StatefulSet it can create split brain, which is exactly why StatefulSet pods are not force-deleted automatically.
There are two other paths worth knowing. Unbound Pending pods can be scheduled onto another eligible node. A bound Pod is not moved in place, even if still Pending; its controller needs a replacement Pod after the old one is removed. And a graceful drain (kubectl drain) is a different mechanism entirely: it cordons the node, then evicts pods through the Eviction API, which respects PodDisruptionBudgets and can block indefinitely if a PDB cannot be satisfied.
If you need faster failover, the levers are the toleration seconds on the pod spec, which you can lower deliberately for stateless workloads, and the node monitor grace period on the controller. Both trade false positives for speed, and lowering them across the board turns a brief network blip into a cluster-wide reschedule storm. My default is to leave them alone and fix availability with more replicas across more nodes, which lets surviving replicas serve while failure detection and replacement proceed.
Separate traffic recovery from pod replacement
Consider three API replicas spread across three nodes. When one node becomes unreachable, the surviving two may continue serving once traffic stops selecting the failed endpoint. Customer recovery can precede creation of the third replica, provided the remaining capacity can handle the load. Measure endpoint withdrawal and successful requests separately from controller replacement time.
For a single-writer workload, the decision is harder. Loss of control-plane connectivity does not prove that the original process stopped writing to storage. Before force-deleting its pod or attaching storage elsewhere, obtain the required fencing evidence from the infrastructure or storage system. Record who established that the old writer can no longer act.
Read the actual pod tolerations and cluster configuration before estimating a timeline. DaemonSet pods and explicitly configured workloads can tolerate these taints differently. The default arithmetic is a useful model, but neither eviction eligibility nor a replacement pod being created guarantees that application failover has completed.
What interviewers probe next
"Why is a StatefulSet pod not recreated automatically?" Because identity must be unique. Kubernetes cannot prove the old one is gone, so recreating postgres-0 while the original may still be writing risks two writers. It requires a human or an operator to assert the node is really dead.
"How does a PodDisruptionBudget interact?" It governs voluntary disruption such as drains and upgrades. It does not stop involuntary eviction from a node that has actually failed.
"What does a topology spread constraint buy you here?" When configured with appropriate topology keys and hard constraints, it can prevent all replicas landing on one node or zone, which is what turns a single node failure into a full outage.
Common mistakes
Saying pods are rescheduled immediately. Six minutes is a long time in an incident and the difference matters.
Not knowing the toleration mechanism, then being unable to answer how to make it faster.
Assuming a drain and a failure follow the same path. One respects PDBs and one does not.
References