Skip to main content
A node in Not Ready state stops accepting workloads and can destabilize the cluster. This procedure assumes a Kubernetes cluster in the selected region, kubectl with the cluster kubeconfig, and — for log inspection — SSH access to worker nodes via a floating IP.

​
Step 1. List and describe the node

Run the following command to list all nodes and their readiness status: 
kubectl get nodes
Identify the node that reports NotReady in the STATUS column, then inspect its details: 
kubectl describe node <NODE_NAME>
This command returns conditions, capacity, and allocatable resources for the node.

​
Conditions

The Conditions section reports disk, memory, and readiness status. The fields have the following meanings:
  • MemoryPressure shows whether the node is under memory pressure.
  • DiskPressure indicates whether disk usage has reached a critical level.
  • PIDPressure indicates whether too many processes are running on the node.
  • Ready is the primary indicator. When the node is in a Not Ready state, this field shows False.

​
Capacity and allocatable resources

These fields show the resources available to the node, such as CPU, memory, and the number of pods it can host. The available resources must meet cluster workload requirements.
  • Capacity resources are resources the node has physically available.
  • Allocatable resources are the resources the node can allocate to pods after subtracting the overhead from the capacity (resources used by Kubernetes to manage the node).
Compare allocatable resources against capacity because major discrepancies can indicate resource exhaustion or improper configuration.

​
Step 2. Check Kubelet logs

When node conditions do not explain the issue, connect to the affected worker node and inspect Kubelet logs. Kubelet manages the node lifecycle, and Kubelet failures often cause nodes to appear as Not Ready. Assign a floating IP to the node if one is not attached yet, then connect with the following command: 
ssh ubuntu@<FLOATING_IP_ADDRESS> -i "<PATH_TO_PRIVATE_SSH_KEY>"
After connecting, examine the Kubelet logs for authentication, certificate, or network errors. When Kubelet runs as a systemd service, use the following command: 
journalctl -u kubelet
This command displays logs generated by the Kubelet service. Common issues include:
  • Certificate errors indicate that the node cannot authenticate with the cluster because certificates are expired or incorrect.
  • Authentication errors can imply misconfigured or missing service accounts or tokens.
  • Network errors can indicate that Kubelet cannot communicate with the control plane or other nodes.
An example log output could look like this: 
Dec 10 12:35:41 node-name kubelet[1256]: E1210 12:35:41.123456 kubelet_node_status.go:92] Unable to register node "nodename" with API server: Unauthorized
In this case, Kubelet reports authentication errors when registering the node with the API server, which typically causes the node to appear in a Not Ready state.

​
Step 3. Address errors

After identifying the root cause, apply the appropriate fix. Common solutions based on the problem type:
  • Resource exhaustion: When a node runs out of CPU, memory, or disk, scale the cluster by adding nodes, upgrading hardware, or adjusting pod resource limits and requests.
  • Network issues: When Kubelet cannot reach the API server or other nodes, verify the node network configuration, DNS settings, and firewall rules that might block required communication.