nginx - 内部负载平衡以及docker swarm v1.12的机制是什么

Question

Docker Swarm模式实现了内部负载平衡，据我所知，nginx被称为硬负载平衡，zookeeper有点像软负载平衡。

那么Doc​​ker v1.12附带的内部负载平衡的机制是什么？

是否在其内部嵌入了Nginx或类似Zookeeper之类的方法？

Answer 1

“内部”负载平衡？不完全是。
Commit ea4fef2将其记录为( docs/swarm/key-concepts.md )为

Swarm uses ingress load balancing to expose the services you want to make available externally to the Swarm.
Swarm can automatically assign the service a PublishedPort or you can configure a PublishedPort for the service in the 30000-32767 range.
External components, such as cloud load balancers, can access the service on the PublishedPort of any node in the cluster, even if the node is not currently running the service.

Swarm has an internal DNS component that automatically assigns each service in the Swarm DNS entry.
Swarm uses internal load balancing to distribute requests among services within the cluster based upon the services' DNS name.

现在( docker 2016年8月1.12日)，内部负载平衡无法持续工作: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 issue 1077说明尚无计划

provide capabilities for session stickiness (cookie-based etc.) in this router mesh.
As awesome as it would be, not all apps are stateless, and we need to route users to the proper container in certain cases

因为:

since we do load balancing at L3/L4 it cannot be bases on things like session cookie.
The best that can be done is to have Source IP based stickiness.

源IP并不总是足够好:

That wouldn't work for our case.
We would have an upstream load balancer (F5) which would make traffic appear to come from a single IP, the "SNAT pool" IP on the F5 since it is a full proxy.
Effectively, Source IP based stickiness would cause all requests to go to one container since all the source IPs would come from the same address.

因此内部负载均衡器仍然非常“基本”:

The main issue with adding "session stickyness" is that there are a hundred ways to do it.
It is also an L7 feature, whereas our load balancing operates at L3/4.

There are two high-level paths here:

• Monitor events coming from the docker API to modify F5 state to route directly task slots.
• Integrate with libnetwork and have the loadbalancer operate as an L7 LB would if it were running directly in the swarm.

现在的结论是:

If you want to handle all aspects of load balancing and not use IPVS, you can disable it by running services in DNSRR mode. You can run any load balancer inside of swarm to do load balancing, bypassing the service VIP and populate backends with the DNSRR entries.

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