Introduction

When kubelet logs say node "master01" not found, kubelet is usually talking to the API server successfully but cannot find a Node object with the name it thinks it owns. That usually points to a registration problem, a hostname mismatch, or a node that was deleted and never re-created correctly.

What the error means

Kubelet periodically updates the status of its node object. For that to work, three things must line up:

• the machine's node name
• the kubelet configuration that tells it what name to use
• the Node resource stored in the API server

If kubelet believes its name is master01 but the API server has no Node with that exact name, status updates fail and you start seeing not found messages.

This is different from a pure network outage. With a network outage you usually see connection or TLS errors. With node not found, kubelet often reaches the API server but references the wrong object.

Check the name kubelet is using

Start by confirming the operating system hostname and the kubelet configuration:

hostname
hostnamectl
journalctl -u kubelet -n 100 --no-pager

Then inspect the kubelet config and startup flags for any explicit override:

grep -R "hostnameOverride\\|--hostname-override" \
  /var/lib/kubelet /etc/systemd/system /etc/default /etc/sysconfig 2>/dev/null

If kubelet is using master01 but the actual registered node is master01.example.internal, or vice versa, the names will never match. The fix is to make kubelet use the exact name the cluster expects, then restart kubelet.

Confirm whether the node object exists

From a machine with cluster access, check the node list:

kubectl get nodes -o wide
kubectl get node master01 -o yaml

Possible outcomes:

• the node exists with a different name
• the node was deleted
• the node never registered successfully

If the node object is gone, kubelet may be trying to update something that no longer exists. In kubeadm-style clusters, restarting kubelet may trigger re-registration if bootstrap credentials are still valid. In more broken cases, the node may need to rejoin the cluster.

Look at certificates and bootstrap state

Node registration relies on valid kubelet credentials. If the client certificate is expired, missing, or tied to a different node identity, kubelet can behave inconsistently during registration.

Useful checks include:

ls -l /var/lib/kubelet/pki
sudo openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -noout -subject -dates

Also verify the kubelet kubeconfig points at the expected API server:

grep server: /etc/kubernetes/kubelet.conf /var/lib/kubelet/kubeconfig 2>/dev/null

If the kubelet was copied from another node, restored from backup, or renamed without regenerating config, stale identity files are a common cause.

Re-registration is sometimes the real fix

If the node object was intentionally deleted or the host was rebuilt, you may need to let the node join again cleanly rather than trying to patch around the error. In kubeadm environments that can mean resetting the broken state and rejoining with a fresh token.

Do that carefully. A control-plane node named master01 may also be running critical workloads, so understand whether this is a worker, a control-plane node, or both before making destructive changes.

Common Pitfalls

The biggest mistake is assuming node not found means the API server is down. Often the API server is reachable and the real problem is identity mismatch.

Another common issue is renaming a host without updating kubelet configuration, certificates, or cloud-provider metadata. Kubernetes treats node names as stable identities.

Teams also delete the node object with kubectl delete node and expect kubelet to recover automatically. Sometimes it does, sometimes it does not, especially if bootstrap or certificate state is already unhealthy.

Finally, do not ignore exact spelling and FQDN differences. master01, master01.local, and master01.example.com are different node names to Kubernetes.

Summary

• 'node "master01" not found usually means kubelet is using a node name the API server does not have.'
• Check hostname, kubelet overrides, and the actual Node objects in the cluster.
• Verify kubelet certificates and kubeconfig, especially after rebuilds or hostname changes.
• If the node was deleted or rebuilt, a clean re-registration may be required.
• Treat node identity as stable and exact, including FQDN differences.