与码头群v1.12一起实现内部负载平衡的机制是什么

Question

码头群模式实现内部负载平衡，据我所知，nginx被称为硬负载平衡，动物园管理员是软负载平衡。

那么，Dockerv1.12附带的内部负载平衡机制是什么呢？

它是否嵌入了一个nginx或类似的方法，如动物园管理员？

Answer 1

“内部”负载平衡？不完全同意。

提交ea4fef2将它(docs/swarm/key-concepts.md)记录为

want使用入口负载平衡来公开您希望向群集外部提供的服务。 Swarm可以自动为服务分配PublishedPort，也可以在30000-32767范围内为服务配置PublishedPort。 外部组件(如云负载平衡器)可以访问集群中任何节点的PublishedPort上的服务，即使该节点目前没有运行该服务。 S群有一个内部DNS组件，可以自动分配群集DNS条目中的每个服务。 S群使用内部负载平衡来根据服务的DNS名称在集群内的服务之间分发请求。

现在(2016年8月1日12月)，内部负载平衡不一致：第25325期

http://10.218.3.5:30000 i i是272dd0310a95 curl http://10.218.3.5:30000 0.01s用户0.01s系统6% cpu 0.217总cpu~ time curl http://10.218.3.5:30000 curl：(7)未能连接到10.218.3.5端口30000:操作超时

第1077期说明目前还没有计划

提供会话粘性(基于cookie等)的功能在这个路由器网中。 尽管如此，并不是所有的应用程序都是无状态的，在某些情况下，我们需要将用户路由到适当的容器。

因为：

由于我们在L3/L4进行负载平衡，所以不能以会话cookie为基础。 最好的做法是要有基于源IP的粘性。

源IP并不总是足够好：

对我们的案子不起作用。 我们将有一个上游负载均衡器( F5 )，它将使流量看起来来自一个IP，即F5上的"SNAT池“IP，因为它是一个完整的代理。 实际上，基于源IP的粘性会导致所有请求转到一个容器，因为所有源IP都来自同一个地址。

因此，内部负载均衡器仍然相当“基本”：

添加“会话粘性”的主要问题是有上百种方法可以做到这一点。 它也是一个L7特性，而--我们的负载平衡在L3/4上运行。 这里有两条高级路径：

• 监视来自docker的事件，以修改F5状态以直接路由任务槽。
• 与LB集成，并让负载平衡器作为一个L7 LB运行，如果它是直接运行在蜂群中。

目前的结论是：

如果希望处理负载平衡的所有方面，而不使用IPVS，则可以通过在DNSRR模式下运行服务来禁用IPVS。您可以在群集中运行任何负载均衡器来实现负载平衡，绕过服务VIP并使用DNSRR条目填充后端。

这就是为什么最新的1.12版本在PR 827中增加了对DNSRR模式和禁用入口的支持。