内部负载平衡与docker swarm v1.12的机制是什么？

Question

Docker Swarm模式实现内部负载均衡,据我所知,nginx称为硬负载均衡,zookeeper是一种软负载均衡.

那么内部负载平衡与Docker v1.12一起出现的机制是什么？

它是否嵌入了nginx或类似于zookeeper的类似方法？

Answer 1

"内部"负载平衡？不完全是.
提交ea4fef2文件it(docs/swarm/key-concepts.md)为

Swarm使用入口负载平衡来公开您希望在Swarm外部提供的服务.
Swarm可以自动分配服务a PublishedPort,也可以PublishedPort为30000-32767范围内的服务配置a .
外部组件(例如云负载平衡器)可以访问PublishedPort群集中任何节点上的服务,即使该节点当前未运行该服务也是如此.

Swarm有一个内部DNS组件,可自动分配Swarm DNS条目中的每个服务.
Swarm使用内部负载平衡,根据服务的DNS名称在集群内的服务之间分配请求.

现在(docker 1.12 August 2016),内部负载平衡不能始终如一地发挥作用:issue 25325

?  ~ time curl http://10.218.3.5:30000
I'm 272dd0310a95
curl http://10.218.3.5:30000  0.01s user 0.01s system 6% cpu 0.217 total
?  ~ time curl http://10.218.3.5:30000
curl: (7) Failed to connect to 10.218.3.5 port 30000: Operation timed out

并且swarmkit问题1077说明还没有计划

在此路由器网格中提供会话粘性(基于cookie等)的功能.
尽管很棒,但并非所有应用程序都是无状态的,在某些情况下我们需要将用户路由到适当的容器

因为:

因为我们在L3/L4上进行负载均衡,所以它不能基于会话cookie之类的东西.
可以做的最好的事情是使源IP基于粘性.

源IP并不总是足够好:

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

因此内部负载平衡器仍然非常"基本":

添加"会话粘性"的主要问题是有一百种方法可以做到这一点.
它也是L7功能,而我们的负载平衡工作在L3/4.

这里有两条高级路径:

• 监视来自docker API的事件以修改F5状态以直接路由任务槽.
• 与libnetwork集成并使负载均衡器作为L7 LB运行,如果它直接在群中运行.

目前的结论是:

如果要处理负载平衡的所有方面而不使用IPVS,可以通过在DNSRR模式下运行服务来禁用它.您可以在swarm中运行任何负载均衡器来进行负载均衡,绕过服务VIP并使用DNSRR条目填充后端.

这就是为什么最新版本1.12与PR 827一起增加了对DNSRR模式的支持并禁用了入口.