Skip to main content
RunBook Academy

KubernetesCXXIV · Node TroubleshootingNode troubleshooting

NotReady and unknown nodes — the heart of the worker

Advanced⏱ ~16 minkubectl

What you'll learn

  • Apply the 11-step methodology to a NotReady node
  • Distinguish NotReady from Unknown
  • Diagnose the node heart, the kubelet, and the runtime
  • Identify the production failure modes of NotReady and Unknown nodes

Prerequisites

Verified against Kubernetes 1.34.x · kubeadm 1.34.x · kubectl 1.34.x · etcd 3.6.x · CoreDNS 1.11.x · containerd 1.7.x / 2.x · 2026-08-16

Not yet marked complete on this device.

A node that stops reporting does not take its Pods with it: they keep running, keep serving traffic, and keep their volumes attached while the control plane works out whether the node is broken or merely unreachable. A Ready condition of False means the kubelet is alive and saying something is wrong; Unknown means nothing has renewed the node lease within the grace period and the control plane has stopped hearing from it at all. kubectl get nodes prints NotReady for both, and the two need opposite investigations — one on the node, one between you and it.

The node heart

A node’s heart is the kubelet’s lease. The kubelet renews the lease every 10s (default). The node controller checks the lease; if the lease is not renewed for 40s (default), the node is marked NotReady.

flowchart TD
    A[kubelet] -->|Renew lease every 10s| B[Node lease]
    B --> C{Lease renewed?}
    C -->|Yes| D[Node Ready]
    C -->|No| E[Mark NotReady]
    E --> F[Evict Pods]

A NotReady node is one whose kubelet has not renewed the lease.

The node conditions

The node’s conditions are the cluster’s view of the node’s state:

# Substitute your own value before running:
NODE=worker-03

kubectl describe node "$NODE"

A real node’s conditions:

Conditions:
  Type             Status  LastHeartbeatTime                 Reason                       Message
  ----             ------  -----------------                 ------                       -------
  Ready            True    Fri, 16 Aug 2026 04:23:01 +0000   KubeletReady                 kubelet is posting ready status
  MemoryPressure   False   Fri, 16 Aug 2026 04:23:01 +0000   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure     False   Fri, 16 Aug 2026 04:23:01 +0000   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure      False   Fri, 16 Aug 2026 04:23:01 +0000   KubeletHasSufficientPID      kubelet has sufficient PID available

The diagnostic is the Ready condition. If Ready is False, the node is NotReady.

The diagnostic

The canonical diagnostic:

# Substitute your own value before running:
NODE=worker-03

# 1. Check the node's conditions
kubectl describe node "$NODE"

# 2. Check the kubelet's logs (run on the node itself)
journalctl -u kubelet -n 200

# 3. Check the runtime's logs (run on the node itself)
journalctl -u containerd -n 200

# 4. Check the node's resources
kubectl top node "$NODE"

# 5. Check the node's events
kubectl get events --field-selector involvedObject.name="$NODE"

The diagnostic is the node conditions, the kubelet logs, the runtime logs, and the resources.

NotReady vs Unknown

A NotReady node is one whose kubelet has reported NotReady. The kubelet is running but the node is not in a usable state.

An Unknown node is one whose kubelet has not reported at all. The kubelet cannot be reached. The node is unreachable from the control plane.

flowchart TD
    A[Node status] --> B{kubelet reachable?}
    B -->|Yes| C[NotReady]
    B -->|No| D[Unknown]
    C --> E[Fix kubelet]
    D --> F[Fix network or kubelet]

The diagnostic is the kubelet’s reachability.

Common causes of NotReady

  • Kubelet failing. The kubelet is in CrashLoopBackOff.
  • Runtime failing. The containerd is failing.
  • Resource pressure. The node is in MemoryPressure or DiskPressure.
  • Network partition. The node cannot reach the API server.

Common causes of Unknown

  • Network partition. The node cannot reach the API server.
  • Kubelet is dead. The kubelet process is crashed.
  • Node is dead. The node is unreachable (e.g., power off).

The remediation

The remediation depends on the cause:

# Substitute your own values before running. NODE is the name the API server
# knows the node by; NODE_SSH is the address you reach it on:
NODE=worker-03
NODE_SSH=worker-03.example.com

# Option 1: Restart the kubelet (run on the node itself)
systemctl restart kubelet

# Option 2: Restart the containerd (run on the node itself)
systemctl restart containerd

# Option 3: Drain and replace the node
kubectl drain "$NODE" --ignore-daemonsets --force

# Option 4: Reboot the node
ssh "$NODE_SSH" "sudo reboot"

The remediation is the node recovery.

Production discipline

A NotReady or Unknown node is the cluster’s hypothesis. The discipline is to walk the 11-step methodology applied to the node, identify the cause, apply the remediation. The node is the cluster’s worker; the remediation is the node recovery.

  • Check the node conditions. The conditions are the cluster’s view.
  • Check the kubelet logs. The kubelet is the node’s voice.
  • Check the runtime logs. The runtime is the node’s container engine.

Quiz

Knowledge check · 4 questions

  1. Q1. What is the difference between a NotReady and Unknown node?

  2. Q2. An Unknown node is unreachable from the control plane.

  3. Q3. An operator reports that a node is `NotReady`. The kubelet logs show `failed to connect to the API server`. What is the diagnostic and remediation?

    The cluster is a 1.34.x kubeadm install. The node is `node-03`. The node's condition is `Ready: False`. The kubelet logs show `failed to connect to the API server`. The node can ping the API server's IP but the API server is unreachable.

  4. Q4. Name three common causes of a NotReady node and the diagnostic command for each.

Passing score: 75%. Answers are checked in this browser.