TL;DR: Nothing happens immediately. 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 toleration period of 300 seconds by default. 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. Detection plus the usual toleration is roughly six minutes before eviction becomes eligible. 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.
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?" It stops all replicas landing on one node or one 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