4

我有一个在虚拟机上运行的分布式应用程序，其中我有一个服务以主动/被动模式运行。活动虚拟机通过公共 IP 提供服务。如果主动 VM 发生故障，公共 IP 将被移动到被动 VM，被动 VM 将变为主动并开始提供服务。

这种模式如何适应 Kubernetes 管理的容器化应用程序？

如果我使用副本数 = 1 的复制控制器，则在节点/minion 故障的情况下，复制控制器将在另一个 minion 中重新安排 pod（= 我当前应用程序中的 VM），但这可能会导致与我当前的解决方案相比的高停机时间仅移动 IP 资源的位置。

如果我使用具有副本数 = 2 的复制控制器，那么我需要对两个 pod（一个具有公共 IP，另一个没有）进行不同的配置，这是反模式？此外，kubernetes 中没有设计方法来支持虚拟 IP（在 pod 周围移动。）？

或者我应该使用replicas = 2并自己实现一些东西来管理IP（或者可能使用pacemaker？这会引入另一个问题：我的应用程序、kubernetes和pacemaker/corosync中会有集群管理）

那么，这应该怎么做呢？

4

1 回答 1

4

听起来您的应用程序在充当负载均衡器的两个 VM 之间使用自己的主选举方案，并且您在内部知道哪个是当前主节点。

今天，这可以在 Kubernetes 中使用跨越 pod（主和备用）的服务和只为当前活动的主服务器返回成功的就绪探测来实现。就绪探测失败会从端点列表中删除 pod，因此不会将流量定向到不是主节点的节点。当您需要进行故障转移时，备用服务器会向就绪探测器报告健康状况（而主服务器会报告不健康或无法访问），此时服务的流量只会落在备用服务器上（现在充当主服务器）。

您可以使用外部 IP 创建跨越两个 pod 的服务，以便可以从集群外部访问它。

于 2015-03-25T22:41:41.237 回答