How Kubernetes Decides Which Nodes Run What: Control Plane vs Worker Nodes

Who's the Boss: Master vs Workers node in Kubernetes

So you’re learning Kubernetes (why? just kidding) and have watched a couple of videos, blogs, tutorials, or maybe even asked an AI tool to explain Kubernetes and its components.

By now, you’ve probably heard about clusters, control planes, nodes, pods, and the good old master and worker nodes.

But have you ever wondered how Kubernetes actually decides which node is the master and which ones are workers?

If you have, you’re in the right place.

---

What Actually Runs on These Nodes?

Before we go any further, let’s quickly look at what runs on these machines:

• The Control Plane: Mainly consists of the kube-apiserver, etcd, scheduler, and controller-manager. These components are responsible for managing the cluster and making decisions about what should happen.

• Worker Nodes: On the other side, a worker node runs components like the kubelet, kube-proxy, and a container runtime.

The Big Reveal: When you’re setting up a Kubernetes cluster from scratch using kubeadm, the machines initially have the same basic building blocks installed. That includes your container runtime, kubelet, and kubeadm.

At this point, nothing magically makes one machine a “master” and the others “workers” — the roles are determined during the cluster initialization and joining process.

So let’s go step-by-step and set up our very own master and worker nodes.

---

Step 1: Install the Basic Blocks on All Physical Computers

First, we install the basic Kubernetes components on all the machines:

• Container runtime, such as containerd
• kubelet
• kubeadm

At this point, all the machines are basically prepared in the same way.

---

Step 2: Decide Which Node Gets to Be the Boss (Master Node)

We need to select one node to become the master node, which will basically handle the control plane of the cluster (simplified).

This decision usually depends on things like the machine's hardware (memory, CPU, etc.) and its role in the cluster.

After deciding on that machine (node), we use the kubeadm init command to initialize the control plane:

sudo kubeadm init --pod-network-cidr=10.244.0.0/16

What happens when we use this command?

kubeadm initializes this machine as the control-plane node.

It generates the cryptographic TLS certificates required for the components to communicate securely.

It also sets up and starts the control-plane components such as the API server, scheduler, controller manager, and etcd.

The crucial step: after these steps, it prints out a secure token and join command that can be used by other machines to join the cluster, looking something like this:

kubeadm join 192.168.1.100:6443 \
  --token abcdef.1234567890abcdef \
  --discovery-token-ca-cert-hash sha256:xyz...

---

Step 3: Log Into the Other Machines to Make Them Worker Nodes

Copy and paste the join command generated by the control-plane node onto each of your other machines.

sudo kubeadm join 192.168.1.100:6443 \
  --token abcdef.1234567890abcdef \
  --discovery-token-ca-cert-hash sha256:xyz...

What happens when you run this command?

This machine uses the IP address provided in the command to connect to the API server.

It presents the token to prove that it is allowed to join the cluster.

The control plane validates the request and the node completes the bootstrap process.

The kubelet on the worker node then registers itself with the API server and basically says:

"I am ready to serve you, master. Send me the containers whenever you want."

---

Step 4: The Verification Phase

Once each node has joined and everything in the network is up and running, you need to verify your setup.

Open up your laptop and run:

kubectl get nodes

In the output, you will see the name, status, roles, age, and version of each node.

By looking at the roles and names, you can see that the nodes have been assigned their respective roles.

Something like:

NAME           STATUS   ROLES           AGE   VERSION
control-plane  Ready    control-plane   10m   v1.xx.x
worker-1       Ready    <none>          8m    v1.xx.x
worker-2       Ready    <none>          8m    v1.xx.x

---

Summary

Before learning advanced tools, you need the big picture first.

A cluster is just a bunch of machines waiting for an assignment.

You decide which machine becomes the brain and which ones do the work.

kubeadm init initializes the control plane, while kubeadm join allows other machines to join the cluster as worker nodes.

Once you understand this simple split, everything else in Kubernetes starts making much more sense.

I hope you’ve learned something new today!

If that’s the case, please do appreciate this post by liking it, or if you have any doubts or suggestions, do write them below — I’ll be happy to take them.

Tada, see ya!