A Kubernetes Node marked NotReady may still have running containers: the status says what the control plane can confirm about the node, not whether every local process has stopped. To find out why traffic continues, check the affected Pod’s readiness and Service EndpointSlices separately from the node status, then trace the actual traffic path. A standard Service uses Pod readiness to determine backend eligibility, so traffic still reaching the application does not by itself prove that the NotReady node remains a ready Service backend.
What NotReady means—and what it does not mean
The node’s Ready condition is a control-plane health signal. If the kubelet cannot report status or the node cannot communicate with the control plane, the Node may become NotReady even while containers continue running locally. The control plane may not be able to confirm their state or promptly change it. See Kubernetes’ Nodes documentation and its explanation of what happens after a node restart.
Distinguish two conditions when inspecting the node: Ready=False is associated with the node.kubernetes.io/not-ready taint; Ready=Unknown is associated with node.kubernetes.io/unreachable. The condition and taint describe different evidence than a container’s local runtime state or a Service’s current backend list.
Why traffic can continue
The application process is still running
A node can lose contact with the control plane without its containers immediately stopping. In that situation, the application might still respond through a network path that remains available, even though Kubernetes cannot reliably manage or observe the workload.
#1 Best Overall
The Pod may no longer be an eligible Service backend
For a standard Kubernetes Service, Pod readiness determines backend eligibility. A Pod’s Ready condition is false when its Node’s Ready condition is not true, and unready Pods are removed from Service load balancers. Kubernetes explains that the kubelet uses readiness probes to determine when a container is ready to accept traffic in its probe documentation.
Therefore, if users still reach the application, verify where the requests actually go. They may be reaching another ready backend, an external load balancer or ingress path, a data plane with stale configuration, or a connection that was already established. These are possibilities to check, not a diagnosis: the cluster’s EndpointSlices and network architecture determine which applies.
Pod deletion and eviction may not happen immediately
The not-ready and unreachable taints use NoExecute behavior by default, but tolerations affect when Pods are evicted. In the usual case, Pods automatically receive a 300-second toleration for these taints; that is a default toleration period, not a guaranteed eviction deadline. Explicit Pod or controller tolerations can change it, and DaemonSet Pods receive indefinite tolerations for these taints. Eviction can also be rate-limited, and an unreachable API server may be unable to tell the kubelet to delete Pods until communication returns. Review the Kubernetes taints and tolerations guidance and node documentation.
Diagnose the node, Pod, and Service separately
- Confirm node condition, taints, and timing. Run
kubectl get nodes, thenkubectl describe node <node>orkubectl get node <node> -o yaml. Check theReadycondition, other conditions, taints, events, and the age of the latest status or lease update. Kubernetes recommends these node-inspection commands in its cluster troubleshooting guide. - Inspect the affected Pod’s actual state. Run
kubectl get pods -A -o wide, thenkubectl describe pod <pod> -n <namespace>. Compare the assigned node and Pod IP with itsstatus.conditions, container state, deletion status, and events. A container that is running locally is not necessarily a Pod that the control plane considers ready. - Check Service backend membership. Inspect the Service’s EndpointSlices and compare their ready endpoint addresses with the affected Pod IP. For example, use
kubectl get endpointslices -n <namespace> -l kubernetes.io/service-name=<service> -o yaml. If the Pod IP is absent or not ready, the standard Service backend list does not show it as an eligible endpoint; traffic still reaching the application then requires checking another backend or route. - Read taints alongside Pod tolerations. Confirm whether the node has the not-ready or unreachable taint and inspect the affected Pod’s tolerations, including any
tolerationSeconds. Account for controller-level settings and DaemonSet behavior before concluding that an eviction is overdue. - Trace timing and the cluster’s traffic path. Review events and, as appropriate to your architecture, the controller, CNI, kube-proxy or eBPF data plane, ingress, and cloud load-balancer state. Compare when the node became unhealthy with when endpoint membership or routing changed. The applicable components vary by cluster; a Node status alone cannot identify the route serving requests.
Useful commands to start with:
kubectl get nodes
kubectl describe node <node>
kubectl get node <node> -o yaml
kubectl get pods -A -o wide
kubectl describe pod <pod> -n <namespace>
kubectl get endpointslices -n <namespace> -l kubernetes.io/service-name=<service> -o yaml
kubectl get events -A --sort-by=.lastTimestampUse commands appropriate to your Kubernetes version and permissions. EndpointSlice inspection is a practical way to verify Service backend membership against the readiness behavior described in the Kubernetes probe documentation.
Rank #3
How to interpret what you find
| Evidence | What it establishes | What to check next |
|---|---|---|
Node is Ready=False or Ready=Unknown |
The control plane reports the node as not ready or cannot determine its readiness. | Node events, taints, and status or lease update timing. |
Container is running, but Pod Ready is false |
The local process may still be alive, but the Pod is not reporting ready for standard Service backend eligibility. | Pod conditions, probe results, events, EndpointSlices, and any alternate traffic path. |
| Pod IP is absent or not ready in the Service’s EndpointSlices | The Pod is not shown as a ready backend for that Service in the inspected EndpointSlice state. | Other ready endpoints, ingress or external load balancer, data-plane state, and established connections. |
| Pod tolerates the node taint, or eviction is delayed | Pod retention or delayed eviction may be consistent with its tolerations and controller behavior. | Effective Pod and controller tolerations, DaemonSet status, eviction events, and node connectivity. |
EndpointSlice contents are a snapshot of backend state, not a complete trace of a client request. When the observed response seems inconsistent with that snapshot, identify the destination and path that handled the request before attributing it to the NotReady node.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What you need to identify the cause
Kubernetes’ documented behavior explains why a NotReady node can coexist with running containers and why eviction or traffic changes may not be immediate. It does not establish the route used by a particular cluster. To make a root-cause claim, gather the Kubernetes version, Pod tolerations, Service type, EndpointSlice contents, CNI and data-plane design, external load-balancer configuration, and relevant events. Then compare those records with the request destination and timing.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
