在尝试将实验性的 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} 应高于备份服务器上的 ${PRIORITY}。因此，分别为 101 和 100 就足够了。
这些设置让我很惊讶。看来我必须选择哪个系统作为初始主系统，并且必须在节点本身中对此进行“硬”配置。
对我来说，这种“高可用性”设置与我在 Kubernetes 中发现的“宠物”/“牛”类比有所不同。
其他系统（例如 HBase）具有类似的设置（一个活跃领导者和多个备用领导者），并且所有系统都“相同”地配置（通过 ZooKeeper 进行选举）。
有没有办法可以配置 Keepalived（用于 Kubernetes），使得所有节点都有相同的配置，并且它仍然正常工作？
答案1
Kubernetes 本身为应用程序提供“牛群”服务。尽管许多“主”Kubernetes 服务都基于相同的基础架构，但在某些时候，您需要使用较低级别的服务来引导服务，以使其全部启动。
保持活跃按照配置链接 kubernetes docco提供单一虚拟专用网络备份组虚拟 IP 地址作为主服务器之间共享的高可用性端点。
所有节点都配置相同的 VRRP IP 地址（或名称），keepalived 会将该地址移至主节点。“选举”在 keepalived 健康检查和故障转移逻辑中完成。
此方法的替代方法是将负载平衡决策移至外部设备或客户端。您可以在每个节点上运行反向代理 (像 haproxy），可以对 kube-api 服务器进行加权，并完成健康检查。
答案2
我意识到这是一个陈旧的线程，但无论如何我还是认为我应该加入讨论，因为我已经在所有节点上运行了具有相同配置的 KeepaliveD。
在 Debian 上，我们将所有节点初始设置为 BACKUP，并进行某种会增加优先级的健康检查（例如 KeepaliveD 运行了多长时间或对您想要 HA 的本地服务进行健康检查...）
VRRP v2，即 KeepaliveD（至少是我使用过的版本）在 Debian 上运行的版本，具有决胜局功能，如果多个节点上的优先级相同，则“最高 IP”获胜。
如果所有节点同时启动，这可能会导致初始延迟，但在我们使用时这是可以接受的。
希望有所帮助。