> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gcore.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Troubleshooting a node in a "Not Ready" state

A node in **Not Ready** state stops accepting workloads and can destabilize the cluster. This procedure assumes a [Kubernetes cluster](/cloud/kubernetes/clusters/create-a-kubernetes-cluster) in the selected region, [kubectl](/cloud/kubernetes/clusters/connect/install-kubectl-and-connect-to-a-kubernetes-cluster) with the cluster kubeconfig, and — for log inspection — [SSH access](/cloud/kubernetes/clusters/connect/connect-to-your-nodes-via-ssh-using-a-floating-ip-address) 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:

```sh theme={null}
kubectl get nodes
```

Identify the node that reports **NotReady** in the STATUS column, then inspect its details:

```sh theme={null}
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](/cloud/kubernetes/clusters/connect/connect-to-your-nodes-via-ssh-using-a-floating-ip-address) to the node if one is not attached yet, then connect with the following command:

```sh theme={null}
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:

```sh theme={null}
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:

```sh theme={null}
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.