search

qmsk / clusterf

Clustered IPVS load balancer control plane with Docker integration
MIT License
35 stars 4 forks source link

masq hairpinning vs Docker networking support for local VIPs within containers #10

Open SpComb opened 8 years ago

SpComb commented 8 years ago

Using IpvsMethod: "masq" on a Docker host for local container backends is the simplest method in terms of configuration, but it fails at hairpinning: a container connecting to a service with a backend on the same docker bridge (the return path does not pass through the host's IPVS stack).

Ideal situation would be to configure the service VIP as a local route within the docker container, optionally with an IP-IP tunnel endpoint, and using Direct Server Return, avoiding the requirement for a symmetric return path with stateful translation.

SpComb commented 8 years ago

This should probably be optional, whilst retaining support for Docker containers using {"IPVSMethod": "masq"}. The IPVS masq method is required for mapping frontend TCP/UDP ports to different backend TCP/UDP ports. The IPVS droute method ignores the IPVS Dest's port, and forwards the unmodified packet using the original Service port.

SpComb commented 8 years ago

Alternatives to retain the use of IPVS masq would include the use of ebtables BROUTING magic to force bridged packets into the Linux routing code where the IPVS netfilter FORWARD masq return path code would have a chance to mangle them.

Or classical NAT hairpinning involving the additional use of SNAT for connections being forwarded within the docker bridge network...