I think my focus is on how to use this configuration parameter- "controlPlaneEndpoint". It is currently buggy to use "controlPlaneEndpoint". https://kubernetes.io/docs/setup/independent/high-availability/
I really hope you can be patient to see my actual situation.
First, The configuration parameter- "controlPlaneEndpoint" is a vip or a Load balancing, right? So, I configure “controlPlaneEndpoint” with 4 layer load balancing; I tried aws\ali. All the results show that will be probability of timeout during use, and "nodexxx not found" appeared 100% of the time during the installation with kubeadm.
Why is this happening? If I use 4 layers of load balancing in parameter- "controlPlaneEndpoint", There will be network problems. For example, I have three master , ServerA、ServerB、ServerC, I enter the command ”kubectl get pod“ on serverA. There was a 33 percent probability of timeout. Everything is fine when the serverA request is directed to either ServerB or ServerC through the 4 layer load balancing. If the request directed to ServerA itself through the 4-layer load balancing, A timeout is bound to occur.
Because the 4 layer load balancing cannot be used when the ServerA is the server as well as the requestor. This is the network feature of the 4-layer load balancing. Same reason, When I create a new cluster with kubeadm, My first master is serverA. Although ServerA's apiserver is already running in docker and I can telnet ServerA-IP:6443 successful , kubelet will check 4-layer load balancing-IP:prot in parameter- "controlPlaneEndpoint" . So "nodexxx not found" appeared 100% of the time during the installation with kubeadm when I configure “controlPlaneEndpoint”.
In a public cloud environment, such as ali, I can't use keepalived+haproxy. This means that I have to use 7 layers of load balancing for k8s-apiserver ,If I want use parameter- "controlPlaneEndpoint" . right?
How to configure the kubeadm-config with layer 7 load balancing? It is https, I had a problem with kubeadm certification. Is there any documentation?
We are suffering the exact same problem, but with the Azure Load Balancer (Level 4).
1) It fails on the first master node where "kubeadm init" is executed because it tries to communicate with itself through the load balancer.
2) On all the other master nodes where "kubeadm join" is executed, there's a 1/N chance of failure when the load balancer selects the node itself and not any of the (N-1) nodes that are already in the cluster.
We hacked our way by using iptables rules. For instance, in the first node before "kubeadm init" we make iptables to route the load balancer ip to 127.0.0.1:
iptables -t nat -A OUTPUT -p all -d ${FRONTEND_IP} -j DNAT --to-destination 127.0.0.1
Of course we delete the iptables rule after kubeadm init. I'm not recommending anybody to do this, it's a nasty hack and my intention with this post is to compel somebody who may know what we are missing to please post what the right solution is.
To the original poster: I don't think the intention is that we use a Level 7 LB. The documentation is clear when they say that a Level 4 is all that's needed.
I'll post again if we find the right solution.