can't join the second master on lab 16.2

emiliano.sutil

Hi,

I´m having problems joining a second master to the cluster.
I ran this command and I get the next message:

vagrant@secondmaster:~$ sudo kubeadm join k8smaster:6443 --token lmcgs9.mwh1gukep4zrrsrb --discovery-token-ca-cert-hash sha256:c7f09153d5eb1ca4d1aaae5a72563b249893b0c0d5ba4c0f66ff309ab51cbd6e --control-plane --certificate-key 03b1178073e62dada4c46e06e9b9f60ce974806153f3af0e6783d0c410e2e4b9
[preflight] Running pre-flight checks
[WARNING Service-Docker]: docker service is not enabled, please run 'systemctl enable docker.service'
[WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker cgroup driver. The recommended driver is "systemd". Please follow the guide at https://kubernetes.io/docs/setup/cri/
[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'
error execution phase preflight:
One or more conditions for hosting a new control plane instance is not satisfied.

unable to add a new control plane instance a cluster that doesn't have a stable controlPlaneEndpoint address

Please ensure that:

• The cluster has a stable controlPlaneEndpoint address.
• The certificates that must be shared among control plane instances are provided.

To see the stack trace of this error execute with --v=5 or higher
vagrant@secondmaster:~$

what should I check on this situation? how can i check my control plane has a stable controlPlaneEndpoint address?

Thanks in advance

Emiliano

chrispokorni

Hi @emiliano.sutil,

The steps to join the second and third control-plane nodes are based on similar steps from earlier lab exercises when the worker node joined the primary control-plane node. These errors may be the result of an incomplete step either during software packages installation, or /etc/hosts file configured with an incorrect IP address for the "k8smaster" alias instead of the proxy IP and your request not reaching the primary API server.

I would suggest running through these steps one more time with a clean second control-plane node, ensuring that all steps are followed as closely as possible.

Regards,
-Chris

emiliano.sutil

Hi @chrispokorni
Thanks for your answer.

I have repeated the process and I get the same problem.
the ips on the hosts files are:
k8smaster
10.128.1.20 k8smaster k8smaster

ha-proxy
10.128.1.20 k8smaster k8smaster

master:
10.128.1.20 k8smaster k8smaster

secondmaster:
10.128.1.20 k8smaster k8smaster

the haproxy.cfg
backend k8sServers
balance roundrobin
server master 10.128.1.3:6443 check

the 10.128.1.3 is the ip of my master

the http://10.128.1.20:9999/stats/
works fine and when I run
kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8smaster Ready control-plane,master 57d v1.20.1
worker Ready 57d v1.20.1

the stats updates, so I think the haproxy is properly configured.

any idea?

thanks in advance

chrispokorni

Hi @emiliano.sutil,

Your issues are caused by your host naming convention, which is not aligned with the host naming convention presented in the lab guide.

The lab guide introduces three control-plane nodes: master, SecondMaster, and ThirdMaster, with worker and ha-proxy nodes. The k8smaster alias is just that, an alias assigned to the master node for the first 13 chapters (from Ch 3 to Ch 15) and then assigned to the ha-proxy node in Ch 16, to help the cluster identify the one node that captures traffic meant for the control-plane. In the beginning, the master node alone represents the control-plane and it is aliased with k8smaster. In the HA chapter, the ha-proxy node becomes the k8smaster once the control-plane grows from one to three nodes.

In your situation, you have a node with the k8smaster hostname which has one IP address, and you also have the k8smaster alias on the ha-proxy node with the 10.128.1.20 IP address.

This configuration is confusing for cluster traffic management and needs to be cleaned up.

Regards,
-Chris