Welcome to the new Linux Foundation Forum!

Lab 16.2: unable to join second master node

KalleWirschKalleWirsch Posts: 2
edited May 14 in LFS258 Class Forum


i'm stuck in Lab 16.2. I'm not able to join the second master node to the cluster.
I've setup haproxy and changed /etc/hosts so k8s-master does point to haproxy.
I've tested that via curl request: curl -k https://k8s-master:6443 and i get a 403 in JSON Format...so connectivity via haproxy is not an issue.

I try to join the second node as a master like this:

[email protected]:~$ sudo kubeadm join k8s-master:6443 --token pzrft4.7bhbcyqpjzeoemle --discovery-token-ca-cert-hash sha256:4df75f261e68bf47c0117bde46899745956883a592f7f996843698f5d1053876 --control-plane --certificate-key a59d1d7f298e152fd590d891c5b1d7a8749e55101aa2a8c23bcb893bfe863781
[preflight] Running pre-flight checks
        [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 -oyaml'
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 does that mean? Why is the controlPlaneEndpoint not stable?
Any help is welcome. Thanks for having a look!


  • chrispokornichrispokorni Posts: 469

    Hi Peter,

    In the lab exercises, beginning with Lab 3, the master alias is set to k8smaster. From your notes, it seems that you are using a different alias k8s-master. Is this used consistently in your cluster, in all the /etc/hosts files, kubeadm init command parameters, and kubeadm join command? Is your haproxy.cfg correct? Has the IP address changed on the proxy instance or the first master instance?


  • KalleWirschKalleWirsch Posts: 2
    edited May 18

    Hi Chris,

    thank you for your reply and your help. I was busy and couldn't reply earlier.
    Regarding your questiions:

    • Is this used consistently in your cluster, in all the /etc/hosts files, kubeadm init command parameters, and kubeadm join command?
      Yes i did use that consistently, while working through the Labs.
      k8s-master has the gcloud internal ip
      k8s-master-2 has the gcloud internal ip
      k8s-proxy has the gcloud internal ip
      In all /etc/hosts/ files k8s-master is mapped to

    • kubeadm init
      I don't have my kubeadm-config.yaml from Lab 3 anymore, so i cannot answer your question regarding kubeadm init.
      All i know is, that joining worker nodes wasn't a problem.
      The kube adm init command i use to join the new node to the existing master shows also that connectivity is not an issue:
      It's too long to paste it here, but i've attached the output.

    It's possible to curl on the api through the k8s-proxy.

    [email protected]:~$ curl k8s-master:6443 -v
    * Rebuilt URL to: k8s-master:6443/
    *   Trying
    * Connected to k8s-master ( port 6443 (#0)
    > GET / HTTP/1.1
    > Host: k8s-master:6443
    > User-Agent: curl/7.47.0
    > Accept: */*
    * HTTP 1.0, assume close after body
    < HTTP/1.0 400 Bad Request
    Client sent an HTTP request to an HTTPS server.
    * Closing connection 0
    • haproxy config
      haproxy.cfg seems correct to me; i also see traffic in the stats increasing, whle curl'ing on the api.

    • IP change
      The internal IPs from the VMs didn't change.

    Any ideas? Thanks again!

  • chrispokornichrispokorni Posts: 469


    The text file you attached shows kubeadm run as the student user. It should be run by root instead.


Sign In or Register to comment.