The API server remembers the node, but kubelet stopped reporting. The node itself usually tells you why within one journalctl command.
The kubelet hasn't posted its lease. Check `systemctl status kubelet containerd` on the node.
The network plugin on that node failed to start, so kubelet marks the network not ready. Events show 'container runtime network not ready'.
Kubelet client cert expired (or the node's clock drifted), so it can't authenticate — node appears dead from the API's view.
kubectl describe node <node> | grep -A6 Conditionssudo journalctl -u kubelet --since '10 min ago' --no-pager | tail -40sudo systemctl status containerd kubeletkubectl -n kube-system rollout restart daemonset/<cni-name>A NotReady node still shows pods as Running for a grace period — don't trust `kubectl get pods` alone during an outage; the API view lags reality by up to the pod-eviction timeout.
NotReady means the kubelet stopped reporting (or its checks failed): network, kubelet process, or runtime. SchedulingDisabled (cordoned) is a deliberate state. Uncordoning won't fix a NotReady node — fix what the kubelet is complaining about.
Pods on that node get evicted after the not-ready toleration window (default 300s), shifting load abruptly. A flapping node churns the whole cluster's scheduling — treat the node's kubelet/service logs as the primary incident.
Kustomize base with probes, PDBs, and zero-downtime rollouts already wired.
Kubernetes Production Blueprints — $27 →One-time. Yours to modify. Instant download from the NinjaOps template store.
One short email when new fixes and production templates drop. No spam, unsubscribe anytime.