NotReady: The node is not accepting new work and its existing pods are at risk

A NotReady node has a Ready condition that is false or unknown. The scheduler stops placing pods there, and after a toleration period the pods already on it start being evicted.

Applies to: All Kubernetes versions

What it means

The Ready condition is the kubelet's own assertion that the node can run pods. It goes false when the kubelet decides something essential is wrong — no container runtime, no CNI configuration, a failing PLEG health check — and it goes to Unknown when the kubelet stops reporting at all, which the node controller detects after a grace period. Those two are worth separating: false means the kubelet is alive and telling you there is a problem, and the reason field will say what. Unknown means nobody is home, and the reason is about connectivity or a dead kubelet rather than about the node's internals. Either way the node is tainted and, after the taint toleration expires, its pods are evicted and rescheduled elsewhere.

Most common causes

• The kubelet has crashed, been stopped, or cannot reach the API server.
• The container runtime is down, so the kubelet cannot manage containers.
• No CNI configuration is present, which the kubelet reports as the network plugin not being ready.
• The node is out of resources so severely that the kubelet cannot function.
• An expired kubelet client certificate, so it can no longer authenticate.
• The node has been shut down, terminated, or lost network connectivity.
• Disk problems preventing the kubelet from writing its own state.

How to diagnose it

1. Read the condition's reason and message: kubectl describe node NODE. This names the specific failure in most cases.
2. Check the last heartbeat time in the same output — a stale one indicates a communication failure rather than a reported problem.
3. On the node, check the kubelet: systemctl status kubelet and journalctl -u kubelet -n 200.
4. Check the container runtime: systemctl status containerd or the equivalent, and crictl info.
5. Check disk and memory on the node directly, since exhaustion of either can produce this.
6. Check whether several nodes went NotReady at once, which points at the control plane or the network rather than at any node.

How to fix it

1. Restart the kubelet or the container runtime, whichever the logs implicate.
2. Restore the CNI configuration if the message names the network plugin.
3. Free disk space or memory if the node is exhausted.
4. Renew the kubelet's client certificate if it has expired.
5. Delete the node object if the machine is permanently gone, so its pods can be rescheduled promptly.
6. Drain and replace nodes that go NotReady repeatedly rather than restarting them each time.

Notes

Pods on a NotReady node are not evicted immediately. The default toleration for the unreachable and not-ready taints is five minutes, which is deliberate — it avoids mass rescheduling during a brief network blip, at the cost of five minutes of degraded capacity. That value can be tuned per pod for latency-sensitive workloads.

Related

• Unknown — The control plane lost contact with the node
• network plugin is not ready — The node has no usable CNI configuration

Sources

• Kubernetes documentation — Node Status
• Kubernetes documentation — Nodes
• Kubernetes documentation — Taints and Tolerations