在尝试将实验性 Kubernetes 集群（在我的笔记本电脑上的几个虚拟机中）配置为“高可用”时，我发现建议使用 keepalived 和 haproxy 的组合来执行此操作（https://github.com/kubernetes/kubeadm/blob /master/docs/ha-considerations.md#options-for-software-load-balancing）。
查看我阅读的配置设置
${STATE} 对于一个主机是 MASTER，对于所有其他主机是 BACKUP，因此虚拟 IP 最初将分配给 MASTER。
主服务器上的 ${PRIORITY} 应该高于备份服务器。因此，分别为 101 和 100 就足够了。
这些设置让我感到惊讶。似乎我必须选择这些系统中的哪一个作为初始主控系统，并且我必须在节点本身中“硬”配置它。
对我来说，这种“高可用性”设置偏离了我在 Kubernetes 中发现的“宠物”/“牛”类比。
其他系统，例如 HBase，具有类似的设置（一个活动领导者和多个备用领导者），并且都配置“相同”（通过 ZooKeeper 完成选举）。
有没有一种方法可以配置 Keepalived（用于 Kubernetes），使所有节点都具有相同的配置并且仍然可以正常工作？
Kubernetes 本身为应用程序提供“牛”服务。尽管许多“主”kubernetes 服务都基于相同的基础设施，但在某些时候，您需要引导一个具有较低级别的服务来启动它。
链接的 kubernetes docco中配置的keepalived提供了一个VRRP虚拟 IP 地址作为 master 之间共享的高可用性端点。
所有节点都配置相同的 VRRP IP 地址（或名称），keepalived 在主节点周围移动该地址。“选举”在 keepalived 健康检查和故障转移逻辑中完成。
此方法的替代方法是将负载平衡决策移至外部设备或客户端。您可以在每个节点上运行反向代理（如 haproxy），它可以加权 kube-api 服务器并完成健康检查。
我意识到这是一个陈旧的线程，但我认为无论如何我都会插话，因为我在所有节点上运行了具有相同配置的 KeepaliveD。
在 Debian 上，我们将所有节点最初设置为 BACKUP，并进行某种健康检查以提高优先级（例如 KeepaliveD 运行了多长时间，或者对您想要 HA 的本地服务进行健康检查......）
VRRP v2 是 KeepaliveD（至少是我使用过的版本）在 Debian 上运行的版本，它具有决胜局功能，如果多个节点上的优先级相同，则“最高 IP”获胜。
如果所有节点同时启动，这可能会导致初始延迟，但在我们使用它的地方这是可以接受的。
希望有帮助。