使用主备模式的应用程序应如何在Kubernetes中进行容器化?

4
我有一个分布式应用运行在虚拟机上,其中有一个服务以主备模式运行。活动的虚拟机通过公共IP提供服务。如果活动的虚拟机出现故障,公共IP将被移动到备用虚拟机,并且备用虚拟机将变为活动状态并开始提供服务。
这种模式如何适用于由Kubernetes管理的容器化应用程序?
如果我使用副本控制器并设置replicas=1,在节点/从属失败的情况下,副本控制器将在另一个从属中重新安排pod(=当前应用程序中的VM),但与我的当前解决方案相比,这可能会导致高停机时间,因为只移动IP资源。
如果我使用副本控制器并设置replicas=2,则需要具有两个不同配置的pod(一个带有公共IP,另一个没有),这是反模式?此外,在Kubernetes中没有设计的方法来支持虚拟IP(移动pod)?
还是应该使用replicas=2并自己实现IP管理(或者可能利用pacemaker?这将引入另一个问题:在我的应用程序中将有两个集群管理,Kubernetes和pacemaker/corosync)?
那么,应该如何处理呢?

你不能一直在两个活动副本之间进行负载均衡,有什么原因吗?你的故障转移程序是什么样子的?如果你有一个数据库,那么如果主服务器失败了,你会丢失提交吗? - Robert Bailey
活动/被动虚拟机本身是我应用程序中的负载均衡器。它是唯一提供外部连接的组件。实际上,我有几个活动/被动配对,取决于所需容量。每个配对都有一个公共IP。 - xiaoping yan
故障转移程序目前采用专有的恢复系统实现,基本上它会监控虚拟机,如果活动虚拟机失败,就执行故障转移。我认为资源管理器Pacemaker通过IP资源代理支持这种情况。然而,使用Pacemaker来配合Kubernetes似乎存在冲突,因为它们都提供集群管理功能。 - xiaoping yan
你有考虑过使用带有外部负载均衡器的Kubernetes服务吗?它可以为你提供一个外部IP,并在Pod之间进行负载均衡。 - Robert Bailey
1个回答

5
听起来你的应用程序在两个充当负载均衡器的虚拟机之间使用自己的主选举方案,你知道哪一个是当前的主节点。
要实现这一点,可以在 Kubernetes 中使用一个服务跨越两个 Pod(主节点和备用节点)以及一个 readiness 探针。只有当前活动的主节点返回成功的 readiness 探针才能够保证 Pod 处于就绪状态。如果 readiness 探针失败,则从 endpoints 列表中删除 Pod,因此不会将流量定向到非主节点上。当需要进行故障切换时,备用节点会向 readiness 探针报告健康状况(主节点会报告非健康状态或无法访问),此时流量只会定向到备用节点(现在充当主节点)。
您可以创建一个跨越两个 Pod 的服务,并使用外部 IP 使其可从集群外部访问。

感谢您的帮助。我将检查准备探针。我是否正确理解,我必须在集群的一个 minion 上配置此外部 IP,然后如果此 minion 失败,我将失去服务访问权限,即这里存在单点故障。关于外部负载均衡器,我想让我的应用程序基础设施独立,因此这不是一个选项,对吗? - xiaoping yan
关于外部IP的问题,这取决于您的部署配置。例如,如果您在GCE上运行,则您的外部IP将在一组健康节点之间进行负载平衡。如果您在本地运行,并且想要在两个节点之间共享IP,则可以使用负载均衡器(如Netscaler)将数据包分布到多个主机上,以提高可靠性。 - Robert Bailey

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接