2 minute read

Summary

A control plane alone is not enough to understand normal cluster operations. Joining worker nodes shows how workloads are scheduled across nodes, and CNI is needed for Pod networking and CoreDNS readiness.

The conclusion of this post is that worker join success should be checked through kubectl get nodes, system Pods, Pod network state, and a simple workload scheduling test, not only through the kubeadm join exit code.

Document Information

  • Written on: 2026-04-24
  • Verification date: 2026-04-24
  • Document type: tutorial
  • Test environment: verified in the author’s separate practice environment. OS, node details, and cluster topology are not fixed in this post.
  • Test version: Kubernetes kubeadm official documentation checked on 2026-04-24.
  • Source level: Kubernetes official documentation.
  • Note: Windows worker nodes are outside this post.

Problem Definition

After worker join, “the node appears” and “the cluster is healthy” are not the same. A node can be NotReady, CNI may be missing, and system Pods can be Pending or CrashLooping.

Verified Facts

  • According to kubeadm join documentation, kubeadm join initializes a new Kubernetes node and adds it to an existing cluster. Evidence: kubeadm join
  • According to kubeadm cluster creation documentation, kubeadm init output includes the kubeadm join command to run on worker nodes. Evidence: Creating a cluster with kubeadm
  • According to the same documentation, after installing a Pod network add-on you can check that CoreDNS Pods are Running. Evidence: Creating a cluster with kubeadm
  • According to Kubernetes Components documentation, kubelet ensures that Pods and containers are running on a node. Evidence: Kubernetes Components

Check flow:

# on worker node
sudo kubeadm join <control-plane-host>:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>

# on control plane
kubectl get nodes -o wide
kubectl get pods -A
kubectl describe node <worker-node-name>

Directly Reproduced Results

  • Direct reproduction: I verified the main commands and configuration flow in the author’s practice environment.
  • Documentation check result: official documentation was used to verify the purpose of join and CoreDNS checks after CNI.
  • Needs reproduction: record node state before and after worker join, CoreDNS state before and after CNI, and sample Deployment scheduling results.

Interpretation / Opinion

My judgment is that worker join issues are easier to debug in three layers. First, did the node register with the API server? Second, can kubelet and the container runtime run Pods? Third, does CNI provide Pod networking?

NotReady is a symptom, not a root cause. Check describe node, kubelet logs, and CNI Pod state together.

Limits and Exceptions

This post assumes Linux worker nodes. Windows workers, multi-architecture nodes, GPU nodes, and taint/toleration-dedicated nodes require separate verification.

CNI installation manifests, Pod CIDR requirements, and NetworkPolicy support vary by CNI.

References

댓글남기기

You may also enjoy