A city worker node shows NotReady after a patch window. Investigation finds the kubelet service is stopped. What is the most direct explanation?
Select an answer to reveal the explanation.
Short Explanation
Kubelet is the node’s heartbeat. Stop that service and the control plane soon calls the node NotReady—like a radio that went silent.
Full Explanation
When a city worker node shows NotReady after a patch window and the kubelet service is stopped, the most direct explanation is that without a running kubelet the node cannot heartbeat and is marked NotReady. Kubelet is the node’s radio to the control plane—silence quickly becomes NotReady on the roster.
NotReady does not always mean etcd lost quorum on the worker—etcd quorum is a control-plane concern. It does not always mean the node’s CNI IP pool is full cluster-wide. It does not always mean every Deployment replica count is zero. Those are separate failure modes.
Exam caveat: other causes of NotReady include runtime crashes, network plugin failures, and lost API connectivity—but given a stopped kubelet service, restarting kubelet is the direct fix path.
Operational check: SSH or console to the node, start/enable the kubelet service, watch kubectl get nodes return Ready, and review kubelet logs for post-patch errors before closing the change window. Keep civic change tickets precise: record object names, namespaces, and before/after observations so the next on-call engineer can replay the fix without guesswork. Keep civic change tickets precise: record object names, namespaces, and before/after observations so the next on-call engineer can replay the fix without guesswork.