Every CKA candidate has run kubectl get nodes, seen NotReady, and SSH’d in to restart the kubelet. The troubleshooting guide covers that reflex. What far fewer candidates can explain is everything Kubernetes does between the kubelet going silent and the workloads coming back somewhere else: who notices the node is gone, how long it takes, which taints appear, why a Deployment’s Pods get replaced after about five minutes while a StatefulSet’s Pods sit in Terminating forever, and what the two “node shutdown” features actually change. Those mechanisms are a dependable source of CKA troubleshooting and scheduling questions, they show up again in the KCSA threat model (an attacker who can make nodes look unhealthy can trigger mass evictions), and they are exactly what you need on the day a production node is powered off without warning.
This guide follows one node from its last heartbeat to full recovery. Planned maintenance with cordon and drain is a different path, covered in the node maintenance guide, and the Pod-level stuck-Terminating cases caused by finalizers are in the finalizers and garbage collection guide. Node-pressure eviction, where a healthy kubelet evicts Pods because the node is running out of memory or disk, is covered in the Kubernetes denial-of-service guide. None of those is re-taught here.
Part 1: How the Control Plane Knows a Node Is Alive
A node is “alive” only because its kubelet keeps saying so. It does that in two ways.
Node status updates
The kubelet owns the .status of its Node object: the Ready, MemoryPressure, DiskPressure, PIDPressure and NetworkUnavailable conditions, plus capacity, allocatable, images and addresses. By default the kubelet re-computes status every 10 seconds (nodeStatusUpdateFrequency) but only writes it to the API server when something changed, or at least every 5 minutes (nodeStatusReportFrequency). Writing a full Node status is comparatively expensive, which is why status alone is no longer the heartbeat.
Node leases
The actual heartbeat is a Lease object in the kube-node-lease namespace, one per node, named after the node. The kubelet renews it every 10 seconds; the lease is tiny, so thousands of nodes can heartbeat cheaply.
kubectl get lease -n kube-node-lease
kubectl get lease worker-2 -n kube-node-lease -o yamlapiVersion: coordination.k8s.io/v1
kind: Lease
metadata:
name: worker-2
namespace: kube-node-lease
spec:
holderIdentity: worker-2
leaseDurationSeconds: 40
renewTime: "2026-10-17T09:14:31.482130Z"renewTime is the field to watch. If it is more than a few tens of seconds old, the kubelet on that node is not talking to the API server, whatever kubectl get nodes currently says. Comparing renewTime with the current time is the fastest way to tell “kubelet is dead” from “kubelet is fine but reporting a problem”.
The node lifecycle controller
Inside kube-controller-manager, the node lifecycle controller watches both signals. Two flags set the clock, and both appear in exam questions and in /etc/kubernetes/manifests/kube-controller-manager.yaml on a kubeadm cluster:
| Flag | Default | Meaning |
|---|---|---|
--node-monitor-period | 5s | How often the controller checks each node’s status and lease |
--node-monitor-grace-period | 50s | How long a node may go without a fresh heartbeat before the controller marks it unhealthy. Must be longer than the lease duration (40s) and several multiples of the kubelet’s update frequency |
Older material and many blog posts quote 40s for the grace period. The default was raised to 50s so that it is strictly greater than leaseDurationSeconds; check the actual flag on your cluster before answering a timing question in a lab.
When the grace period expires without a heartbeat, the controller sets the node’s Ready condition to Unknown with reason NodeStatusUnknown and the message Kubelet stopped posting node status. kubectl get nodes prints Unknown as NotReady, which is why so many people never see the distinction:
kubectl get node worker-2 -o jsonpath='{range .status.conditions[?(@.type=="Ready")]}{.status}{"\t"}{.reason}{"\t"}{.message}{"\n"}{end}'
# Unknown NodeStatusUnknown Kubelet stopped posting node status.The distinction matters: Ready=False means the kubelet is alive and reporting that the node is not ready (runtime down, CNI not ready). Ready=Unknown means nobody has heard from the kubelet at all. They lead to different taints.
Part 2: Taints Appear and the Eviction Clock Starts
The automatic taints
As soon as the condition changes, the node lifecycle controller taints the node:
| Condition | Taint added |
|---|---|
Ready=False | node.kubernetes.io/not-ready with effects NoSchedule and NoExecute |
Ready=Unknown | node.kubernetes.io/unreachable with effects NoSchedule and NoExecute |
MemoryPressure=True | node.kubernetes.io/memory-pressure:NoSchedule |
DiskPressure=True | node.kubernetes.io/disk-pressure:NoSchedule |
PIDPressure=True | node.kubernetes.io/pid-pressure:NoSchedule |
NetworkUnavailable=True | node.kubernetes.io/network-unavailable:NoSchedule |
spec.unschedulable=true (cordon) | node.kubernetes.io/unschedulable:NoSchedule |
The NoSchedule effects stop new Pods landing on the node. The NoExecute effects are what evict running Pods, and only not-ready and unreachable carry NoExecute. The pressure taints never evict by themselves; node-pressure eviction is the kubelet’s job.
kubectl describe node worker-2 | grep -A3 Taints
# Taints: node.kubernetes.io/unreachable:NoExecute
# node.kubernetes.io/unreachable:NoScheduleThe 300-second default toleration
A NoExecute taint evicts any Pod that does not tolerate it, immediately. So why do Pods survive on an unreachable node for about five minutes? Because the API server’s DefaultTolerationSeconds admission plugin adds two tolerations to every Pod that does not already have them:
tolerations:
- key: node.kubernetes.io/not-ready
operator: Exists
effect: NoExecute
tolerationSeconds: 300
- key: node.kubernetes.io/unreachable
operator: Exists
effect: NoExecute
tolerationSeconds: 300tolerationSeconds means “tolerate this taint, but only for this long after it appears”. The defaults come from two API server flags, --default-not-ready-toleration-seconds and --default-unreachable-toleration-seconds, both 300. Run kubectl get pod <name> -o yaml on any Pod you created without tolerations and you will find these two entries injected.
Two consequences the exam tests:
- You tune failover per workload, not per cluster. A Pod that should move within 30 seconds of its node vanishing declares its own
tolerationSeconds: 30for both keys; a batch Pod that should ride out a brief network blip declarestolerationSeconds: 3600. OmittingtolerationSecondsentirely means “tolerate forever”, which is what DaemonSet Pods do. --pod-eviction-timeoutis gone. Old guides describe a 5-minutepod-eviction-timeouton the controller manager. That flag lost all effect when taint-based evictions became the default and has since been removed. The five minutes you observe today isnode-monitor-grace-periodplustolerationSeconds: 300, nothing else.
What “eviction” is here, and what it is not
When the toleration expires, the controller deletes the Pod through the API with the Pod’s normal terminationGracePeriodSeconds. Three details follow from that:
- This is not the Eviction API that
kubectl drainuses, so PodDisruptionBudgets are not consulted. A PDB protects against voluntary disruptions; a dead node is involuntary. Expecting a PDB to save you from a node failure is a classic wrong answer. - The deletion sets
metadata.deletionTimestamp, but the only component that can actually stop the containers and confirm the deletion is the kubelet on the dead node. It cannot, so the Pod object stays inTerminatinguntil the kubelet returns, the Pod is force-deleted, or the node is removed. - DaemonSet Pods are not evicted. The DaemonSet controller gives them
not-readyandunreachabletolerations with notolerationSeconds. Static Pods are owned by the kubelet, not the API, so their mirror Pods are not evicted either.
Zone-aware rate limiting
The controller deliberately does not evict everything at once. Four more kube-controller-manager flags govern the pace, and they are the answer to “why did only some nodes’ Pods get evicted?”:
| Flag | Default | Effect |
|---|---|---|
--node-eviction-rate | 0.1 | Normally, at most one node’s Pods are evicted per 10 seconds |
--unhealthy-zone-threshold | 0.55 | If at least 55% of the nodes in a zone are unhealthy, the zone is treated as unhealthy |
--large-cluster-size-threshold | 50 | Clusters with this many nodes or fewer are “small” |
--secondary-node-eviction-rate | 0.01 | In an unhealthy zone of a large cluster, evictions slow to one node per 100 seconds |
Two more rules sit on top. In a small cluster whose zone becomes unhealthy, evictions stop entirely. And if every zone is unhealthy at once, the controller assumes the control plane itself has lost connectivity and performs no evictions, because mass-evicting healthy workloads on a network partition would be worse than waiting. Zones are determined by the topology.kubernetes.io/zone label, and a cluster with no zone labels is one zone.
Part 3: What Happens to Each Workload Type
The Pod object is stuck in Terminating; whether the application recovers depends on the controller that owns it.
| Owner | Behavior after the Pod is marked for deletion | Why |
|---|---|---|
| Deployment / ReplicaSet | A replacement Pod is created immediately on a healthy node | The ReplicaSet controller does not count a Pod with a deletionTimestamp as active, so it sees too few replicas |
| Job | Replacement Pod created (subject to the Job’s backoff and failure policy) | Same active-Pod logic |
| DaemonSet | Nothing; the Pod is not evicted at all | Tolerates the taints indefinitely |
| Static Pod | Nothing | Managed by the kubelet, not evicted via the API |
| Bare Pod | Gone when the deletion completes; nothing recreates it | No controller |
| StatefulSet | No replacement. The Pod stays Terminating; web-2 cannot be recreated until the old web-2 is confirmed gone | StatefulSet guarantees at most one Pod with a given identity, and it refuses to break that guarantee without proof the old Pod stopped |
The StatefulSet row is the heart of most exam scenarios and most 3 a.m. incidents. Kubernetes cannot know whether the node is truly dead or merely partitioned from the control plane with web-2 still running, still holding its volume and still serving writes. Creating a second web-2 elsewhere could corrupt data, so the controller waits. Volumes compound the problem: a ReadWriteOnce PersistentVolume attached to the dead node stays attached until the attach/detach controller is sure it is safe to detach, so even a manually recreated Pod can sit ContainerCreating with Multi-Attach error.
There are four ways out, from safest to most dangerous:
- The node comes back. The kubelet reconnects, sees the
deletionTimestamp, terminates the containers, the Pod is removed, and the StatefulSet recreates it. The taints are removed as soon as the heartbeat returns; if that happens before the 300 seconds expire, nothing is evicted at all. - Apply the out-of-service taint (Part 5). This is the supported way to say “I have verified the node is powered off” and lets Kubernetes force-delete the Pods and detach the volumes safely.
- Delete the Node object with
kubectl delete node worker-2. The Pod garbage collector removes Pods bound to a node that no longer exists, so stuck Pods disappear and controllers recreate them. Appropriate when the machine is permanently gone. - Force-delete the Pod with
kubectl delete pod web-2 --force --grace-period=0. This removes the Pod object from etcd without any confirmation from the kubelet. If the node is actually still running, you now have twoweb-2Pods, and the StatefulSet’s at-most-one guarantee is broken. The documentation calls this out as a last resort for a reason.
Part 4: The Timeline, Minute by Minute
Put the defaults together for a node that loses power at t=0 with no shutdown features configured:
| Time | What happens |
|---|---|
t=0 | Power is cut. The kubelet, containers and Pods on the node stop. Nothing in the control plane knows yet |
t≈0-10s | The kubelet’s next lease renewal never arrives. renewTime stops advancing |
t≈50s | node-monitor-grace-period expires. The node lifecycle controller sets Ready=Unknown and adds node.kubernetes.io/unreachable with NoSchedule and NoExecute. The scheduler stops placing Pods there. kubectl get nodes shows NotReady |
t≈50s-5m50s | Pods keep tolerating the taint for their tolerationSeconds (300 by default). Service endpoints for those Pods are still listed as ready by the EndpointSlice controller because the Pod status has not changed, so clients may be sent to dead Pods during this window. Readiness probes do not help; there is no kubelet to run them |
t≈5m50s | Tolerations expire. The controller deletes the Pods (rate-limited to one node per 10 seconds). Each Pod gets a deletionTimestamp and shows Terminating. ReplicaSets and Jobs create replacements on healthy nodes right away. StatefulSet Pods are stuck |
t≈5m50s-12m | RWO volumes still show attached to the dead node. The attach/detach controller eventually force-detaches volumes from a node that has been unhealthy for its timeout (six minutes by default; the flag --disable-force-detach-on-timeout turns that off), after which replacement Pods elsewhere can mount them |
| Until kubelet returns or an operator acts | StatefulSet Pods remain Terminating. Resolve with the out-of-service taint, a node deletion, or (last resort) a force delete |
If the power returns at t=3m, the kubelet heartbeats, the taints are removed, the containers are restarted by the kubelet on the same node, and no eviction ever happens. The 300-second toleration is a deliberate trade: fast failover versus not thrashing workloads on every short network blip.
Part 5: The Two Node-Shutdown Features
Everything above describes the control plane reacting to a node that simply vanished. Two kubelet-side features change the story when the shutdown is detectable or when you can confirm it afterwards.
Graceful Node Shutdown
Graceful Node Shutdown lets the kubelet notice that the operating system is shutting down (a reboot, systemctl poweroff, a cloud-initiated stop that goes through the OS) and terminate its Pods in order before the machine goes away, instead of them dying mid-write. It relies on systemd inhibitor locks: the kubelet registers a delay inhibitor with systemd-logind, so when a shutdown is requested logind pauses for up to the inhibitor’s delay while the kubelet terminates Pods. The kubelet also writes a drop-in to raise logind’s InhibitDelayMaxSec so the delay is long enough.
It is configured in the KubeletConfiguration file (/var/lib/kubelet/config.yaml on kubeadm clusters), not with flags:
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
shutdownGracePeriod: 30s
shutdownGracePeriodCriticalPods: 10sThe two values define two phases. In the first shutdownGracePeriod - shutdownGracePeriodCriticalPods (20 seconds here) the kubelet terminates all regular Pods. In the remaining shutdownGracePeriodCriticalPods (10 seconds) it terminates critical Pods, those with the system-cluster-critical or system-node-critical priority class, so that networking, DNS and logging agents stay up until the application Pods are gone. If a Pod’s terminationGracePeriodSeconds is longer than the phase allows, it is cut short. Both values default to 0, which means the feature is inactive even though its feature gate is enabled by default, and “enable graceful node shutdown” in a lab means setting these two fields and restarting the kubelet.
Pods terminated this way are marked Failed with reason Terminated and the message Pod was terminated in response to imminent node shutdown. They are not evicted through the API, and because the kubelet knows exactly what happened, the Pods complete termination properly instead of hanging in Terminating. Controllers then replace them as usual. The node is also marked NotReady with reason KubeletNotReady during the shutdown so new Pods are not scheduled onto it.
For finer control, Graceful Node Shutdown based on Pod priority replaces the two-phase model with a list, so you can give databases more time than stateless web Pods:
shutdownGracePeriodByPodPriority:
- priority: 100000
shutdownGracePeriodSeconds: 10 # critical system Pods, last to go
- priority: 10000
shutdownGracePeriodSeconds: 180 # databases
- priority: 1000
shutdownGracePeriodSeconds: 120
- priority: 0
shutdownGracePeriodSeconds: 60 # everything else, first to goPods are terminated from the lowest priority band upward, each band getting its configured time. You configure either the two-field form or the priority list, not both.
Limits that matter for exam reasoning: the feature needs systemd and logind on Linux (Windows support arrived later as a separate feature gate), and it only helps when the shutdown is visible to the OS. A pulled power cable, a hypervisor crash or a hard reset never triggers logind, which is why the second feature exists.
Non-Graceful Node Shutdown and the out-of-service taint
When a node dies without warning, the kubelet never gets to clean up, and you land in the Part 3 situation: StatefulSet Pods in Terminating, volumes still attached. Non-Graceful Node Shutdown (generally available since Kubernetes 1.28) gives an operator a safe, declarative way to say “I have confirmed this node is really down”:
kubectl taint nodes worker-2 node.kubernetes.io/out-of-service=nodeshutdown:NoExecuteThe taint key is node.kubernetes.io/out-of-service; the value is free-form (the docs use nodeshutdown) and the effect can be NoExecute or NoSchedule. Two controllers react to it:
- The Pod garbage collector force-deletes the Pods on that node that are terminating and do not tolerate the taint, so StatefulSet Pods are finally removed and recreated elsewhere.
- The attach/detach controller detaches volumes from the node immediately, without waiting for the six-minute force-detach timeout, so the recreated Pods can mount their PersistentVolumes.
Preconditions and clean-up are the exam details: the node must already be NotReady (or Unknown), you must be certain the node is powered off or otherwise cannot be running the workloads (that is your responsibility, not Kubernetes’), and you should remove the taint after the node is repaired and rejoins, or after you delete the Node object:
kubectl taint nodes worker-2 node.kubernetes.io/out-of-service=nodeshutdown:NoExecute-Compared with kubectl delete pod --force, the out-of-service taint is safer because it also handles volume detachment and works for every stuck Pod on the node in one step. Compared with kubectl delete node, it keeps the Node object (and its labels, taints and capacity) for when the hardware returns.
Part 6: The Pod Garbage Collector’s Other Jobs
Several recoveries above depend on the Pod garbage collector in kube-controller-manager, so know what it cleans up:
- Orphaned Pods: Pods bound to a node that no longer exists in the API (the
kubectl delete nodepath). - Terminating Pods on out-of-service nodes: the non-graceful shutdown path.
- Unscheduled terminating Pods: Pods deleted before the scheduler ever placed them.
- Terminated Pods above the threshold: once the number of
SucceededorFailedPods passes--terminated-pod-gc-threshold(default12500), the oldest are deleted. This is why a cluster with many short Jobs occasionally loses old completed Pods and their logs.
Part 7: A Debugging Sequence for the Exam
When a question or a lab says “Pods on worker-2 are not running and new Pods are not being scheduled there”, this order gets you to the cause fastest:
# 1. Is the node Ready, False, or Unknown? What taints does it carry?
kubectl get nodes
kubectl describe node worker-2 | sed -n '/Taints/,/Unschedulable/p'
kubectl get node worker-2 -o jsonpath='{.status.conditions[?(@.type=="Ready")].message}{"\n"}'
# 2. When did the kubelet last heartbeat?
kubectl get lease worker-2 -n kube-node-lease -o jsonpath='{.spec.renewTime}{"\n"}'
# 3. Which Pods are stuck, and who owns them?
kubectl get pods -A -o wide --field-selector spec.nodeName=worker-2
kubectl get pod web-2 -n db -o jsonpath='{.metadata.deletionTimestamp}{"\n"}{.metadata.ownerReferences[0].kind}{"\n"}'
# 4. What tolerations were injected, and how long will Pods wait?
kubectl get pod web-2 -n db -o jsonpath='{range .spec.tolerations[*]}{.key}{" "}{.effect}{" "}{.tolerationSeconds}{"\n"}{end}'
# 5. What are the controller's timing defaults on this cluster?
grep -E 'node-monitor|eviction-rate|unhealthy-zone' /etc/kubernetes/manifests/kube-controller-manager.yaml
# 6. On the node itself (if reachable): is the kubelet alive, is shutdown handling configured?
ssh worker-2 'sudo systemctl status kubelet --no-pager; sudo grep -E "shutdownGracePeriod" /var/lib/kubelet/config.yaml'Then act: fix the kubelet if the node is reachable; apply the out-of-service taint if it is confirmed dead; delete the Node object if the machine is gone for good.
Common Mistakes
- Expecting a PDB to stop evictions from a dead node. PDBs apply to the Eviction API (drain). Taint-based eviction deletes Pods directly.
- Looking for
--pod-eviction-timeout. It no longer exists. TunetolerationSecondson the Pods instead. - Setting
tolerationSecondson only one of the two keys.not-readyandunreachableare different taints for different conditions; set both. - Assuming
shutdownGracePeriodhas a useful default. It is0. The feature does nothing until you set it. - Giving critical Pods a longer
terminationGracePeriodSecondsthan the critical phase. They are cut short atshutdownGracePeriodCriticalPods. - Force-deleting StatefulSet Pods on a node that might still be running. Two Pods with the same identity can corrupt the volume. Use the out-of-service taint after confirming the node is down.
- Forgetting to remove the out-of-service taint after the node returns; it carries
NoExecuteand will evict everything scheduled there. - Reading
NotReadyas one state.Ready=FalseandReady=Unknownare different, produce different taints, and point at different fixes.
Practice It Before the Exam Does
Node failure questions in the CKA are practical: a node is NotReady, Pods are Terminating, a StatefulSet will not recover, and the clock is running. The same mechanisms appear across the KubeAstronaut exams, from CKA troubleshooting to the KCSA threat-model questions about an attacker triggering evictions by disrupting heartbeats. The fastest way to make the timeline instinctive is to break a node in a disposable cluster, watch the lease stop renewing, watch the taints arrive at the grace period, and practice each recovery path. The KubeAstronaut mock exam bundle includes performance-based CKA troubleshooting scenarios of exactly this shape across its CKA, CKAD, CKS, KCNA and KCSA mock exams, with explanations that walk through the heartbeat, taint and eviction logic rather than just the command. Pair it with the CKA troubleshooting guide and the node maintenance guide so planned and unplanned node outages are both second nature.
Frequently Asked Questions
How long does it take for Kubernetes to notice a node is down?
About 50 seconds with default settings. The kubelet renews its Lease in kube-node-lease every 10 seconds; when the node lifecycle controller sees no heartbeat for --node-monitor-grace-period (default 50s, formerly 40s), it sets the node’s Ready condition to Unknown and taints it node.kubernetes.io/unreachable.
Why do Pods on a NotReady node take 5 minutes to be evicted?
The DefaultTolerationSeconds admission plugin injects tolerations for node.kubernetes.io/not-ready and node.kubernetes.io/unreachable with tolerationSeconds: 300 into every Pod that does not define its own. The Pods tolerate the NoExecute taint for 300 seconds, then the controller deletes them. Set your own tolerationSeconds on both keys to change the delay per workload.
What happened to pod-eviction-timeout?
The --pod-eviction-timeout controller-manager flag stopped having any effect once taint-based evictions became the default behavior, and it has since been removed. Eviction timing is now controlled by --node-monitor-grace-period plus each Pod’s tolerationSeconds.
Why does a StatefulSet Pod stay in Terminating when its node dies, while Deployment Pods are replaced?
A ReplicaSet does not count a Pod with a deletion timestamp as active, so it creates a replacement immediately. A StatefulSet guarantees at most one Pod per ordinal identity and will not recreate web-2 until the old web-2 is confirmed terminated, which an unreachable kubelet cannot confirm. Resolve it with the node.kubernetes.io/out-of-service taint, by deleting the Node object, or, only if you are sure the node is off, a force delete.
Does a PodDisruptionBudget protect Pods when a node fails?
No. PDBs apply to voluntary disruptions that go through the Eviction API, such as kubectl drain. Taint-based eviction after a node failure deletes Pods directly and does not consult PDBs.
What is the difference between graceful and non-graceful node shutdown?
Graceful Node Shutdown is a kubelet feature that detects an OS shutdown through systemd inhibitor locks and terminates Pods in phases (shutdownGracePeriod and shutdownGracePeriodCriticalPods, or a per-priority list) before the machine stops. Non-Graceful Node Shutdown is for shutdowns the kubelet never saw: an operator applies the node.kubernetes.io/out-of-service taint to a confirmed-dead node, and the Pod garbage collector force-deletes its Pods while volumes are detached immediately.
How do I enable graceful node shutdown on a kubeadm cluster?
Set shutdownGracePeriod and shutdownGracePeriodCriticalPods (both default to 0, which disables the behavior) in /var/lib/kubelet/config.yaml and restart the kubelet with systemctl restart kubelet. The node must run systemd with logind. For per-workload timing, use shutdownGracePeriodByPodPriority instead of the two fields.
Are DaemonSet Pods evicted when a node becomes unreachable?
No. The DaemonSet controller adds tolerations for not-ready and unreachable with no tolerationSeconds, so they tolerate the taints indefinitely. Static Pods are also not evicted because the kubelet, not the API server, owns them.
Key Takeaways
- The heartbeat is the Lease in
kube-node-lease, renewed every 10 seconds; Node status is written only on change or every 5 minutes. - The node lifecycle controller marks a silent node
Ready=Unknownafter--node-monitor-grace-period(50s default) and addsunreachabletaints; a kubelet that reports problems getsReady=Falseandnot-readytaints. - Only
not-readyandunreachablecarryNoExecute; the defaulttolerationSeconds: 300injected byDefaultTolerationSecondssets the five-minute delay.--pod-eviction-timeoutis gone. - Taint-based eviction ignores PDBs, skips DaemonSet and static Pods, and is rate-limited per zone (
0.1nodes/s,0.55unhealthy threshold,50-node small-cluster rule,0.01secondary rate, no evictions when all zones are unhealthy). - Deployments recover immediately; StatefulSet Pods stay
Terminatinguntil the kubelet returns, the node is deleted, the out-of-service taint is applied, or a risky force delete. - Graceful Node Shutdown:
shutdownGracePeriodandshutdownGracePeriodCriticalPodsinKubeletConfiguration(default0), two phases via systemd inhibitor locks, Pods endFailedwith reasonTerminated. - Non-Graceful Node Shutdown:
node.kubernetes.io/out-of-service=nodeshutdown:NoExecuteon a confirmed-dead node force-deletes stuck Pods and detaches volumes at once; remove the taint afterwards.