我有一个在虚拟机上运行的分布式应用程序，其中我有一个服务以主动/被动模式运行。事件虚拟机通过公共(public) IP 提供服务。如果主动 VM 发生故障，公共(public) IP 将被移动到被动 VM，被动 VM 将变为主动并开始提供服务。
这种模式如何适应 Kubernetes 管理的容器化应用程序？
如果我使用副本数 = 1 的复制 Controller ，则在节点/minion 故障的情况下，复制 Controller 将在另一个 minion 中重新调度 pod(= 我当前应用程序中的 VM)，但这可能会导致与我当前的解决方案相比的停机时间较长仅移动 IP 资源的位置。
如果我使用具有副本数 = 2 的复制 Controller ，那么我需要对两个 pod(一个具有公共(public) IP，另一个没有)进行不同的配置，这是反模式？此外，kubernetes 中没有设计方法来支持虚拟 IP(在 pod 周围移动。)？
或者我应该使用replicas = 2并自己实现一些东西来管理IP(或者可能使用pacemaker？这会引入另一个问题:我的应用程序、kubernetes和pacemaker/corosync中会有集群管理)
那么，这应该怎么做呢？
最佳答案
听起来您的应用程序在充当负载均衡器的两个 VM 之间使用自己的主选举方案，并且您在内部知道哪个是当前主节点。
今天，这可以在 Kubernetes 中使用跨越 pod(主和备用)的服务和只为当前事件的主服务器返回成功的就绪探测来实现。就绪探测失败会从端点列表中删除 pod，因此不会将流量定向到不是主节点的节点。当您需要进行故障转移时，备用服务器会向就绪探测器报告健康状况(而主服务器会报告不健康或无法访问)，此时服务的流量只会落在备用服务器上(现在充当主服务器)。
您可以使用外部 IP 创建跨越两个 pod 的服务，以便可以从集群外部访问它。
关于kubernetes - 使用主动/被动冗余模型的应用程序应该如何使用 Kubernetes 进行容器化？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29226725/