Adding a worker node to a Kubernetes cluster

You can use the supplied token at the time of Kubeadm init to execute it on the worker node.

To have a node join a cluster, we need to perform a bi-directional trust between the nodes and the cluster.

1. Node Discovery

kubeadm downloads necessary cluster information from the API server. By default, it uses the bootstrap token and the CA key hash to verify the authenticity of that data. The root CA can also be discovered directly via a file or URL.

2. TLS Bootstrap

Once the cluster information is known, kubelet can start the TLS bootstrapping process. The TLS bootstrap uses the shared token to temporarily authenticate with the Kubernetes API server to submit a certificate signing request (CSR); by default the control plane signs this CSR request automatically.

root@worker2:~# kubeadm join <master server ip>:6443 — token <toke> \
> — discovery-token-ca-cert-hash sha256:cb6
[preflight] Running pre-flight checks
[preflight] Reading configuration from the cluster…
[preflight] FYI: You can look at this config file with ‘kubectl -n kube-system get cm kubeadm-config -o yaml’
W0501 01:15:43.998308 1509169 utils.go:69] The recommended value for “resolvConf” in “KubeletConfiguration” is: /run/systemd/resolve/resolv.conf; the provided value is: /run/systemd/resolve/resolv.conf
[kubelet-start] Writing kubelet configuration to file “/var/lib/kubelet/config.yaml”
[kubelet-start] Writing kubelet environment file with flags to file “/var/lib/kubelet/kubeadm-flags.env”
[kubelet-start] Starting the kubelet
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap…
This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.
Run ‘kubectl get nodes’ on the control-plane to see this node join the cluster.

Now you can check on the master node for the nodes joined in the cluster

admin@master:~$ kubectl get nodes
NAME                  STATUS ROLES                AGE VERSION
master.testlab.local  Ready  control-plane,master 36m v1.23.1
worker1.testlab.local Ready  <none>               20s v1.23.1
worker2.testlab.local Ready  <none>               2m8s v1.23.1

You should see the following PODS running in the kube-system namespace now.

admin@master:~$ kubectl get pods -A
NAMESPACE     NAME                                           READY   STATUS    RESTARTS   AGE
kube-system   coredns-64897985d-5zdtt                        1/1     Running   0          37m
kube-system   coredns-64897985d-9zf48                        1/1     Running   0          37m
kube-system   etcd-master.testlab.local                      1/1     Running   1          37m
kube-system   kube-apiserver-master.testlab.local            1/1     Running   0          37m
kube-system   kube-controller-manager-master.testlab.local   1/1     Running   0          37m
kube-system   kube-proxy-4hdw6                               1/1     Running   0          37m
kube-system   kube-proxy-f6wwt                               1/1     Running   0          3m31s
kube-system   kube-proxy-jf66g                               1/1     Running   0          103s
kube-system   kube-scheduler-master.testlab.local            1/1     Running   1          37m

Ready for some fun now. Your thoughts :)