简谈docker swarm中负载均衡原理

同一集群内部的负载均衡模式

基于在swarm中创建节点即可分配内部域名的情况下：

1. dnsrr 单纯通过内部DNS内部组件进行负载均，由于DNS缓存机制等问题，有局限性。
2. VIP：
   简单来讲是 (内部)DNS+VIP(iptable+ipvs转发，ipvs有几种算法一般使用轮询；据说K8S的内部负载均衡的实现方案也用了ipvs是非常相似的)
3. Routing Mesh
   在创建节点时，如果增加了端口映射 (对外端口) 8080 : 80 (容器端口)，该节点会加入 ingress overlay network。集群中每个节点(包括manager节点)的80端口都会增加ipvs转发规则，将请求转发至目标节点之一。这个架构称之为routing mesh。

图中括号出列出了两种模式的说明示意。在（Routing Mesh）处，容器C5实际运行的是其他无关服务并没有运行在80端口的服务，但仍能将请求转发至实际服务(之一)。

资料1
资料2
资料3

扩展

既然集群内部实现了负载均衡，那么套在多个集群的网关节点上的负载均衡，以此实现多层负载均衡。

问题

已知某容器内的webservice，意图通过 HTTP HEADERS中的x-forwarded-for，获得客户端的真实IP；但实际拿到的是该集群中的某个节点ip或者容器IP。已知ipvs只修改报文中的mac地址，不改IP；由此提出假设，在docker swarm中，“网关”在转发报文时修改了ip报文中的源ip。
当时查阅资料及尝试后，没有找到合理解决办法。无奈新写一个webservice 用来获取client的ip,但不放在docker swarm集群中，而是手动运行容器，规避了这个问题。