內部負載平衡與docker swarm的機制是什麼v1.12

Question

Docker Swarm模式實現內部負載平衡，據我所知nginx被稱爲硬負載平衡，zookeeper是一種軟負載平衡。

那麼內部負載平衡與Docker v1.12一起出現的機制是什麼？

是否在內部嵌入了一個nginx或類似zookeeper的方法？

Answer 1

「內部」負載平衡？不完全是。
Commit ea4fef2文件它（docs/swarm/key-concepts.md）作爲

羣使用進入負載均衡暴露你要提供內外兼修的羣的服務。
Swarm可以自動分配服務a PublishedPort或者您可以爲30000-32767範圍內的服務配置PublishedPort。
即使節點當前沒有運行服務，外部組件（如雲負載平衡器）也可以訪問羣集中任何節點的PublishedPort上的服務。

Swarm有一個內部DNS組件，可以自動分配Swarm DNS條目中的每個服務。
Swarm使用內部負載平衡根據服務的DNS名稱在集羣內的服務之間分配請求。

眼下（搬運工1.12 2016年8月），即內負載分擔並不一致地工作：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。

有兩個高層次的路徑在這裏：

從泊塢窗API來

• 監視事件來修改F5狀態直接路由任務插槽。
• 與libnetwork集成並使負載均衡器作爲L7 LB運行，如果它直接在羣集中運行。

的結論，現在是：

如果要處理負載平衡的各個方面，而不是使用IPVS，您可以通過在DNSRR模式下運行的服務禁用它。您可以運行羣集中的任何負載均衡器來執行負載平衡，繞過服務VIP並使用DNSRR條目填充後端。

這就是爲什麼最新版本1.12與PR 827增加了對DNSRR模式的支持並禁用入口。