我在虚拟机上运行了一个分布式应用程序，其中我有一个服务在主动/被动模式下运行。活动VM通过公共IP提供服务。如果活动VM发生故障，公共IP将被移动到被动VM，被动VM将变为活动状态并开始提供服务。
这种模式如何适合kubernetes管理的容器化应用程序？
如果我使用replicas = 1的复制控制器，在节点/ minion失败的情况下，复制控制器将在其他minion中重新安排pod（=我当前appciation中的VM），但这可能会导致比我的更长的停机时间当前只有IP资源移动的解决方案。
如果我使用replicas = 2的复制控制器，那么我需要使用两个pod（一个具有公共IP，另一个没有）具有反模式的不同配置？更进一步，kubernetes中没有设计方法来支持虚拟IP（移动aroud pod。）？
或者我应该使用replicas = 2并自己实施一些东西来管理IP（或者可能使用心脏起搏器？这会引入另一个问题：我的应用程序中会出现cluser管理，kubernetes和pacemaker / corosync）
那么，应该怎么做呢？
答案 0 :(得分：3)
听起来您的应用程序在充当负载均衡器的两个VM之间使用自己的主选举方案，并且您在内部知道哪个是当前的主服务器。
今天可以在Kubernetes中使用跨越pod（主服务器和备用服务器）的服务以及只返回当前活动主服务器成功的就绪调查来实现。准备探测失败会从端点列表中删除pod，因此不会将流量定向到不是主节点的节点。当您需要进行故障转移时，备用数据库会向准备情况探测报告正常（并且主服务器将报告运行状况不佳或无法访问），此时服务的流量只会落在备用服务器上（现在充当主服务器）。
您可以使用外部IP创建跨两个pod的服务，以便可以从群集外部访问它。