1

我目前正在尝试使用 Docker Swarm 在三节点集群上以高度可用的方式设置我们的应用程序（由无状态和有状态服务组成）。对于“高度可用”，我的意思是“可以承受三个节点中的一个节点的故障”。

我们一直在进行此类安装（使用其他方式，而不是 Docker，更不用说 Docker Swarm），并且取得了很好的成功，包括可接受的故障转移行为，因此我们的应用程序本身（或者构成它的服务）已经/已经证明在这样的三节点设置中，它/它们可以高度可用。

使用 Swarm，我让应用程序成功启动并运行（所有三个节点都启动），并注意我已对每个服务进行了冗余配置，即每个服务都存在多个实例，它们已为 HA 正确配置，并且并非所有服务实例都位于同一个 Swarm 节点上。当然，我也注意到我所有的 Swarm 节点都作为管理节点加入了 Swarm，这样如果原来的领导节点出现故障，它们中的任何一个都可以成为 swarm 的领导者。

在这种“良好”状态下，由于 Swarm 的 Ingress 网络，我可以在任何节点上的暴露端口上访问服务。很酷。在生产环境中，我们现在可以在我们的 swarm 工作节点前面放置一个高可用性负载均衡器，这样客户端就可以连接到一个 IP 地址，并且即使其中一个节点出现故障也不会注意到。

所以现在是测试故障转移行为的时候了……我希望杀死一个 Swarm 节点（即虚拟机的硬关闭）将使我的应用程序继续运行，当然，尽管处于“降级”模式。唉，在关闭之后，我在相当长的一段时间内都无法通过它们暴露的（通过入口）端口访问我的任何服务。有些确实再次变得可访问并且确实已成功恢复（例如，可以再次访问三节点 Elasticsearch 集群，当然现在缺少一个节点，但又回到“绿色”状态）。但是其他人（唉，这包括我们的内部 LB ......）仍然无法通过他们发布的端口访问。

“docker node ls”显示一个节点无法访问

$ docker node ls
ID                           HOSTNAME  STATUS  AVAILABILITY  MANAGER 
STATUS
kma44tewzpya80a58boxn9k4s *  manager1  Ready   Active        Reachable
uhz0y2xkd7fkztfuofq3uqufp    manager2  Ready   Active        Leader
x4bggf8cu371qhi0fva5ucpxo    manager3  Down    Active        Unreachable

正如预期的那样。

关于导致这些影响的 Swarm 设置，我可能做错了什么？我只是在这里期待太多了吗？

4

0 回答 0