Troubleshooting

kubectl get nodes lists every node with its STATUS (Ready / NotReady / SchedulingDisabled), ROLES, AGE, and VERSION. It is the entry point for cluster/node troubleshooting because a NotReady node tells you immediately whether the problem is node-local.

kubectl describe node <name> shows the Conditions block (Ready, MemoryPressure, DiskPressure, PIDPressure, NetworkUnavailable), assigned Taints, Capacity/Allocatable, the list of pods on the node, and the Events section at the bottom.

MemoryPressure (node is low on memory), DiskPressure (node is low on disk/inodes), PIDPressure (too many processes), and NetworkUnavailable (node network not correctly configured). When any of these is True the kubelet may taint the node and evict pods.

Ready=Unknown means the node controller has not heard from the kubelet within the node-monitor grace period (the kubelet stopped posting status/heartbeats). It usually indicates the kubelet is down or the node lost network connectivity to the API server, not that workloads themselves failed.

The kubelet posts the node's Ready status and manages all pods on the node. If it is stopped, crashed, or misconfigured the node reports NotReady (or Unknown). So after confirming with kubectl get nodes, SSH to the node and inspect the kubelet with systemctl and journalctl.

systemctl status kubelet shows the service's active/inactive/failed state, the main PID, recent log lines, and whether it is enabled at boot. Use systemctl restart kubelet to restart it after a config fix.