1

我想我的重点是如何使用这个配置参数——“controlPlaneEndpoint”。目前使用“controlPlaneEndpoint”有问题。 https://kubernetes.io/docs/setup/independent/high-availability/

我真的希望你能耐心看到我的实际情况。

首先，配置参数-“controlPlaneEndpoint”是vip还是负载均衡，对吧？所以，我用 4 层负载均衡配置了“controlPlaneEndpoint”；我试过 aws\ali。所有的结果表明在使用过程中会有超时的概率，并且在使用 kubeadm 安装过程中出现“nodexxx not found”的概率是 100%。

为什么会这样？如果我在参数-“controlPlaneEndpoint”中使用4层负载均衡，就会出现网络问题。比如我有三个master，ServerA、ServerB、ServerC，我在serverA上输入命令“kubectl get pod”。超时的概率为 33%。当 serverA 请求通过 4 层负载平衡定向到 ServerB 或 ServerC 时，一切正常。如果请求通过4层负载均衡定向到ServerA本身，必然会发生超时。

因为当ServerA既是服务器又是请求者时，不能使用4层负载均衡。这就是 4 层负载均衡的网络特性。同样的原因，当我使用 kubeadm 创建一个新集群时，我的第一个 master 是 serverA。虽然 ServerA 的 apiserver 已经在 docker 中运行并且我可以 telnet ServerA-IP:6443 successful ，但 kubelet 会检查 4 层负载平衡-IP:prot 参数-“controlPlaneEndpoint”。因此，当我配置“controlPlaneEndpoint”时，在使用 kubeadm 安装期间，“nodexxx not found”出现 100% 的时间。

在阿里等公有云环境下，无法使用keepalived+haproxy。这意味着我必须为 k8s-apiserver 使用 7 层负载均衡，如果我想使用参数-“controlPlaneEndpoint”。正确的？

如何使用第 7 层负载均衡配置 kubeadm-config？是 https，kubeadm 认证有问题。有文件吗？

4

2 回答 2

5

我们遇到了完全相同的问题，但使用的是 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 OUTPUT -p all -d ${FRONTEND_IP} -j DNAT --to-destination 127.0.0.1

当然我们在 kubeadm init 之后删除了 iptables 规则。我不建议任何人这样做，这是一个令人讨厌的黑客行为，我写这篇文章的目的是迫使可能知道我们缺少什么的人发布正确的解决方案。

致原发帖人​​：我不认为我们的意图是我们使用 7 级 LB。当他们说只需要 4 级时，文档就很清楚了。

如果我们找到正确的解决方案，我会再次发布。

于 2019-07-20T02:54:16.060 回答
0

@pbms 上面的回复很有用：--control-plane-endpoint在 HA 主场景中为您使用 ELB 时，您需要创建Target Groupusing typeIP addresses而不是Instances。该文本在创建目标组时很有帮助：

“促进路由到同一实例上的多个 IP 地址和网络接口。”

我能够使用此设置成功地初始化我的集群：

kubeadm init --control-plane-endpoint "<myELBname>:6443" --upload-certs
于 2022-01-21T09:31:14.323 回答