我认为我的重点是如何使用此配置参数-“ controlPlaneEndpoint”。 当前使用“ controlPlaneEndpoint”是有问题的。 https://kubernetes.io/docs/setup/independent/high-availability/
我真的希望你能耐心看到我的实际情况。
首先，配置参数“ controlPlaneEndpoint”是vip或负载均衡，对吗？ 因此，我将“ controlPlaneEndpoint”配置为具有4层负载平衡。我尝试过aws \ ali。 所有结果表明，使用期间可能会超时，并且在使用kubeadm进行安装的过程中，“ nodexxx not found”的出现时间为100％。
为什么会这样？ 如果我在参数“ controlPlaneEndpoint”中使用4层负载平衡，则将出现网络问题。 例如，我有三个主服务器，即ServerA，ServerB，ServerC，我在serverA上输入命令“ kubectl get pod”。发生超时的概率为33％。 通过4层负载平衡将serverA请求定向到ServerB或ServerC时，一切都很好。 如果该请求通过4层负载平衡指向ServerA本身，则肯定会发生超时。
因为当ServerA既是服务器又是请求者时，无法使用4层负载平衡。 这是4层负载平衡的网络功能。 同样的原因，当我使用kubeadm创建新集群时，我的第一个主服务器是serverA。尽管ServerA的apiserver已经在docker中运行，并且我可以telnet ServerA-IP：6443成功，但kubelet会在参数“ controlPlaneEndpoint”中检查4层负载平衡-IP：prot。因此，当我配置“ controlPlaneEndpoint”时，在使用kubeadm进行安装的过程中，“ nodexxx not found”的出现率为100％。
在诸如ali之类的公共云环境中，我不能使用keepalived + haproxy。 这意味着我必须对k8s-apiserver使用7层负载均衡，如果我想使用参数“ controlPlaneEndpoint”。对吧？
如何使用第7层负载平衡配置kubeadm-config？是https，我对kubeadm认证有疑问。有文件吗？
答案 0 :(得分：1)
我们正在遭受完全相同的问题，但是使用了Azure负载平衡器（级别4）。
1）它在执行“ kubeadm init”的第一个主节点上失败，因为它试图通过负载均衡器与其自身进行通信。
2）在执行“ kubeadm join”的所有其他主节点上，当负载均衡器选择节点本身而不是已经在其中的任何（N-1）个节点时，发生失败的机会为1 / N集群。
我们通过使用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初始化后删除iptables规则。我不建议任何人这样做，这是一个令人讨厌的骇客，我的意图是强迫某些可能知道我们所缺少的人，提出正确的解决方案。
对于原始海报：我不认为我们打算使用7级LB。当他们说仅需要Level 4时，说明文件就清楚了。
如果找到合适的解决方案，我会再次发布。