Docker群集故障转移行为似乎有点令人沮丧

我目前正在尝试使用Docker Swarm在三节点集群上以高度可用的方式设置我们的应用程序（包括无状态服务和有状态服务）。 “高可用”的意思是“能够解决三个节点之一的故障”。

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

使用Swarm，我成功启动并运行了应用程序（所有三个节点均已启动），并且保证每个服务都有冗余configuration，即每个服务都存在多个实例，它们已针对HA进行了正确configuration，并非所有服务的实例都位于同一个Swarm节点上。 当然，我也注意到所有的Swarm节点都join了Swarm作为pipe理者节点，这样如果原来的Leader节点失败，他们中的任何一个都可以成为Swarm的领导者。

在这个“良好”状态下，由于Swarm的Ingressnetworking，我可以在任何节点的暴露端口上获得服务。 很酷。 在生产环境中，我们现在可以将高度可用的负载均衡器放在群集工作者节点的前面，这样客户端就可以拥有一个IP地址来连接，而且如果其中一个节点发生故障，您甚至不会注意到。

所以，现在是testing故障转移行为的时候了……我预计杀死一个Swarm节点（即，VM的硬closures）将使我的应用程序运行，尽pipe处于“降级”模式。 唉，在closures之后，我无法通过他们暴露的（通过Ingress）端口在相当长的时间内到达我的任何服务。 有些可以再次达到，并且确实已经恢复成功（例如，三节点Elasticsearch集群可以再次访问，当然现在缺less一个节点，但是回到“绿色”状态）。 但其他人（唉，这包括我们内部的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设置导致这些影响，我可能会做错吗？ 我只是在这里期待太多？