How to Fix Kubernetes Node Not Ready Error

In this tutorial, you'll learn about How to Fix Kubernetes Node Not Ready Error. We cover key concepts, practical examples, and best practices.

The Problem

Running kubectl get nodes shows one or more nodes as NotReady. Pods on that node stop running, and new pods are not scheduled there. This usually indicates a kubelet issue, resource pressure, or network problem.

Quick Fix

Step 1: Describe the node for details

Find the reason for the NotReady status:

kubectl describe node worker-1

Look for Conditions in the output:

Conditions:
  Type                 Status  LastHeartbeatTime
  ----                 ------  -----------------
  Ready                False   ...
  DiskPressure         False   ...
  MemoryPressure       False   ...
  PIDPressure          False   ...

Step 2: Check kubelet on the node

SSH into the node and check if kubelet is running:

ssh user@worker-1
sudo systemctl status kubelet

kubelet.service - Kubernetes Kubelet
   Active: inactive (dead)

Start and enable kubelet:

sudo systemctl restart kubelet
sudo systemctl enable kubelet

Step 3: Check kubelet logs

If kubelet is running but the node is not ready, check the logs:

sudo journalctl -u kubelet --no-pager -n 50

Look for errors like failed to connect to API server or volume node affinity conflict.

Step 4: Free up disk space

Disk pressure causes nodes to become NotReady. Check disk usage:

df -h

Clean up unused Docker resources:

docker system prune --all --force

Step 5: Check the container runtime

Verify the container runtime is working:

sudo crictl ps

If it fails, restart containerd:

sudo systemctl restart containerd

Step 6: Remove the node and rejoin

If nothing works, drain and remove the node:

kubectl drain worker-1 --ignore-daemonsets --delete-emptydir-data
kubectl delete node worker-1

Then rejoin from the node:

sudo kubeadm join <api-server>:6443 --token <token> --discovery-token-ca-cert-hash <hash>

Alternative Solutions

Check network plugin (CNI) issues

A misconfigured CNI plugin can cause node not-ready:

kubectl get pods -n kube-system | grep -i cni

Check for resource exhaustion at the OS level

An OOM or disk-full condition on the host affects kubelet:

dmesg | tail -20

Common Mistakes to Avoid

Rebooting the node without draining it first. kubectl drain evicts pods gracefully. Rebooting without draining causes service disruption.

Ignoring kubelet certificate expiration. kubelet certificates expire after one year. Check with openssl x509 -in /var/lib/kubelet/pki/kubelet.crt -noout -enddates.

Not checking the container runtime. containerd or CRI-O may be stopped even if kubelet is running. Always check both services.

Pro Tips

Set resource reservations for kubelet. Configure --system-reserved and --kube-reserved in kubelet to ensure system processes have enough resources under pressure.

Monitor node conditions with alerts. Set up Prometheus alerts for kube_node_status_condition{condition="Ready",status="true"} != 1.

Use PriorityClass for critical workloads. Assign high priority to system pods so they are evicted last when the node is under resource pressure.

Prevention

• Set up resource alerts for disk, memory, and PID pressure on nodes.
• Regularly clean up unused container images and volumes.
• Configure kubelet with appropriate --eviction-hard thresholds.