Kubeadm join to control node from worker node failing with api server error

krishnasan

Hi,
I following the chapter 2 exercise and getting following error while joining to master node,

I am using Virtualbox in my local system to configure control/worker node,

Virtualbox version : 7.0.12
Ubuntu : 20.04
user: root

FYI : I have reset my cluster and token multiple times and still getting the same error.

oot@k8s-worker:/home/vboxuser# kubeadm join 10.0.2.15:6443 --token iws0jd.mgsxezm7b4qktodl --discovery-token-ca-cert-hash sha256:22bc9c5b582ca41b8ca43694e32a8b1ef5586742996384e178d73f0302e21196
[preflight] Running pre-flight checks
[WARNING Swap]: swap is enabled; production deployments should disable swap unless testing the NodeSwap feature gate of the kubelet
error execution phase preflight: couldn't validate the identity of the API Server: Get "https://10.0.2.15:6443/api/v1/namespaces/kube-public/configmaps/cluster-info?timeout=10s": dial tcp 10.0.2.15:6443: connect: connection refused
To see the stack trace of this error execute with --v=5 or higher
root@k8s-worker:/home/vboxuser#

chrispokorni

Hi @krishnasan,

The swap warning seems odd because the k8sWorker.sh script is expected to disable swap on the worker node. Did you happen to notice any errors or failures during the execution of that script?

Are the private IP addresses of vbox VMs on the same subnet? Is each VM set with one bridged adapter, with promiscuous mode enabled to allow all traffic? Are the VMs of 2 vCPUs, 6-8 GB RAM and 20 GB disk?

To generate a valid join command with a new token, on the control plane run as root (or prefix with sudo if running as vboxuser non-root user):

root@cp:~$ kubeadm token create --print-join-command

After an unsuccessful join, the worker node needs to be reset by root with (or prefix with sudo if run as vboxuser non-root user):

root@worker:~$ kubeadm reset

Then run the entire join command again as root (or prefix with sudo if run as vboxuser non-root user):

root@worker:~$ kubeadm join ...

Regards,
-Chris

krishnasan

Hi @chrispokorni,

Created a new VirtualBox's with the promiscuous mode enabled solved the issue.

When I follow the Lab 2.3 basic pod creation, the Pod is creating in the worker node though I enabled taint in the control node.

Is this expected behavior?

chrispokorni

Hi @krishnasan,

Removing the control plane taint from the cp node enables it for user pod scheduling, thus being treated as a worker node by the kube-scheduler agent.

In earlier labs it is expected to have user pods scheduled on the worker node, but in later lab exercises the behavior may be more random when both nodes (cp and worker) will evenly share cluster workload.

Regards,
-Chris