我认为我的重点是如何使用此配置参数 - " controlPlaneEndPoint"。目前使用" ControlPlaneEndPoint"是错误的。https://kubernetes.io/docs/setup/indepentent/high-availability/
我真的希望您能耐心看到我的实际情况。
首先，配置参数 - " ControlPlaneEndPoint"是VIP或负载平衡，对吗？因此，我以4层负载平衡配置" ControlPlaneEndPoint"；我尝试了AWS ali。所有结果表明，在使用过程中将是超时的概率，并且在使用Kubeadm安装期间，"找不到Nodexxx"出现了100％的时间。
为什么会发生这种情况？如果我在参数" ControlPlaneEndPoint"中使用4层负载平衡，则将存在网络问题。例如，我有三个主服务器，serverb，serverc，我在servera上输入命令" kubectl get pod"。超时的可能性为33％。当通过4层加载平衡将服务器请求引向ServerB或Serverc时，一切都很好。如果请求通过4层负载平衡向服务器本身引导，则必须发生超时。
因为当服务器是服务器和请求者时，无法使用4层负载平衡。这是4层负载平衡的网络功能。同样的原因，当我使用Kubeadm创建一个新群集时，我的第一个主人是Servera。尽管Servera的Apiserver已经在Docker中运行，并且我可以telnet Servera-IP：6443成功，但Kubelet将检查4层负载平衡-IP：prot in parameter-" controlplaneendpoint"。因此，当我配置" controlplaneendpoint"时，在安装时，"找不到nodexxx"在安装期间出现了100％的时间。
在公共云环境中，例如Ali，我无法使用Keepalived Haproxy。这意味着如果我想使用参数 - " controlPlaneEndPoint"，我必须使用7层负载平衡。对吗？
如何使用第7层负载平衡配置Kubeadm-Config？它是HTTPS，我在Kubeadm认证方面遇到了问题。有任何文档吗？
我们遇到的问题完全相同，但是使用Azure负载平衡器(4级(。
1(它在第一个主节点上失败，其中" kubeadm init"执行，因为它试图通过负载平衡器与自身进行通信。
2(在执行" kubeadm join"的所有其他主节点上，当加载平衡器选择节点本身而不是已经在集群。
我们使用iptables规则攻击了自己的方式。例如，在" kubeadm init"之前的第一个节点中，我们使iptables将负载平衡器IP路由到127.0.0.1：
iptables -t nat -a输出-p all -d $ {frontend_ip} -j dnat - 到期127.0.0.1
当然，我们在kubeadm init之后删除了iptables规则。我不建议任何人这样做，这是一个令人讨厌的黑客，我对这篇文章的意图是强迫某人知道我们缺少的东西来请发布正确的解决方案。
原始海报：我认为我们的意图不是我们使用7级磅。当他们说第4级是所需的时，文档很明显。
如果找到正确的解决方案，我会再次发布。
@pbms上面的回复很有用：在HA主场景中为--control-plane-endpoint使用ELB时，您需要使用类型IP addresses而不是Instances创建Target Group。创建目标组时文本很有帮助：
"促进在同一实例上的多个IP地址和网络接口的路由。"
我能够使用此设置成功地启动我的群集：
kubeadm init --control-plane-endpoint "<myELBname>:6443" --upload-certs