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

Question

Docker Swarm模式实现Inner Load Balancing，据我所知，nginx叫硬负载均衡，zookeeper有点软负载均衡。

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

它是否在内部嵌入了 nginx 或类似 zookeeper 的方法？

Answer 1

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

Swarm 使用 入口负载平衡 将您希望在 Swarm 外部提供的服务公开。
Swarm 可以自动为该服务分配一个PublishedPort，或者您可以为 30000-32767 范围内的服务配置一个PublishedPort。
外部组件（例如云负载均衡器）可以访问集群中任何节点的PublishedPort 上的服务，即使该节点当前没有运行该服务。

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

目前（2016 年 8 月 1.12 日，docker 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 说明目前还没有计划

在此路由器网格中提供会话粘性（基于 cookie 等）的功能。
尽管它很棒，但并非所有应用都是无状态的，在某些情况下我们需要将用户路由到正确的容器

因为：

由于我们在 L3/L4 进行负载平衡，它不能基于会话 cookie 之类的东西。
可以做的最好的事情是拥有基于源 IP 的粘性。

而且源 IP 并不总是足够好：

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

所以内部负载均衡器仍然非常“基本”：

添加“会话粘性”的主要问题是有一百种方法可以做到这一点。
它也是 L7 功能，而我们的负载平衡在 L3/4 上运行。

这里有两个高级路径：

• 监控来自 docker API 的事件以修改 F5 状态以直接路由任务槽。
• 与 libnetwork 集成，让负载均衡器像 L7 LB 一样运行，如果它直接在 swarm 中运行。

现在的结论是：

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

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