我试图在swarm模式下使用docker在生产中实现容器化应用程序集群。
让我描述一个非常简约的场景。 我只有5 个 aws-ec2实例。 这些节点都没有分配公共 IP，并且所有节点都分配了子网的一部分专用 IP。
例如
管理器节点
- 172.16.50.1
- 172.16.50.2
工作器节点
- 172.16.50.3
- 172.16.50.4
- 172.16.50.5
使用上述基础设施，创建了一个 docker 群，第一个节点的 IP (172.16.50.1) 作为 --advertise-addr，以便其他 4 个节点作为管理员或工作线程使用各自的令牌加入群。
我不想通过让管理器节点也扮演工作节点的角色来重载管理器节点。(这是一个好主意还是资源利用不足？
由于每个节点是 4 个核心，因此我托管我的 Web 应用程序的 9 个副本，这些副本分布在 3 个工作节点中，每个工作节点运行 3 个托管我的 Web 应用程序的容器。
现在有了这个设置，我应该如何将带有 VIP(虚拟 IP)的整个 docker 群集群暴露给外部世界以供使用？
请验证我的以下想法：
1. 我是否应该有一个经典的负载均衡器设置，例如保留一个基于 httpd 或 nginx 或 haproxy 的反向代理，该代理分配了公共 IP 并使其平衡负载到上述 5 个节点，其中我们的 部署了 docker-swarm？
我在这里看到的一个缺点是上述反向代理将是单点故障？任何想法如何使其容错/高度可用？我应该尝试AnyCast解决方案吗？
2. 使用 AWS ALB/ELB，它将流量路由到我们群所在的上述 5 个节点。
3. 如果保留一个单独的负载均衡器是要走的路，那么真正的 docker-swarm 负载平衡和服务发现就是全部 大约？
Docker Swarm 向外部客户端公开 1 个虚拟 IP 或主机名以访问 Swarm 集群中的服务的答案是什么？
Docker-swarm 吹捧了很多关于覆盖网络的信息，但不确定它是如何做到的 与我通过VIP向客户端公开集群的问题有关 互联网。我们是否应始终让负载均衡器了解 IP 稍后加入 docker 群的节点的地址？
请说些光亮！
进一步阅读后，我了解到我们在群管理器节点中创建的覆盖网络仅用于容器间通信。
与其他网络模式(如网桥、主机、macvlan)的唯一区别在于，其他模式支持容器之间的通信，而覆盖网络也有助于部署在不同子网中的容器之间的通信。 即多主机容器通信。
以这些知识为线索，通过分配给负载均衡器的单个公共 IP 将 Swarm 暴露给世界，该负载均衡器会将请求分发到所有 Swarm 节点。这只是我在高层次上的理解。
这是我需要您的意见和想法的地方...解释如何处理这个问题的行业标准？