Welcome to the Linux Foundation Forum!

can't join the second master on lab 16.2

emiliano.sutil Posts: 5
edited April 2021 in LFS258 Class Forum


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

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

Thanks in advance



  • chrispokorni
    chrispokorni Posts: 2,208

    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.


  • 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 k8smaster k8smaster

    ha-proxy k8smaster k8smaster

    master: k8smaster k8smaster

    secondmaster: k8smaster k8smaster

    the haproxy.cfg
    backend k8sServers
    balance roundrobin
    server master check

    the is the ip of my master

    works fine and when I run
    kubectl get nodes
    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
    chrispokorni Posts: 2,208

    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 IP address.

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



Upcoming Training