Docker1.12 swarm cluster LB program and application of the original LB program trade-offs?
Docker1.12 swarm comes with IPVS-based load balancing module, based on the order of LB
Assuming that the application is based on Dubbo's application, the client side has a rich LB strategy
At that time there are the following questions?
1. In the swarm mode, how to use the original application of the original LB strategy?
2. In fact, to solve the problem 1, whether it should start from the service discovery, bypass the swarm service found in order to achieve independent LB strategy applications, which is swarm comes with overlay network, dubbo application external exposure, or What should the network settings be?
Map: swarm overlay network, dubbo application external exposed address, external invisible problem
Docker service create --name lv --replicas 3 lv
Docker service create --name lv - p 20880: 20880 --replicas 3 lv
2016-11-04 add comment share it
- Micro letter
Did not find the relevant results
We agreed from:
Talk about personal care, because I swarm and dubbo not how to understand.
The key point is to solve the application outside the container cluster to access the application within the container cluster.
If you deploy a dubbo-based A application to a swarm while ensuring that other legacy deployments (deployed on x86 servers or vm), there are already containerized dubbo-based C applications that are able to access A only Can use dubbo service discovery and LB.
The solution is to solve the deployment of the application to the swarm application container, at the time of registration, register a container cluster can be directly accessed outside the IP.
This is better resolved in the dcos, because marathon can host the host of the ip and nat port through the environment variable way to pass to the container. In the swarm and k8s deal with it may be more trouble.
On the network, to give up the overlay, using MACvlan may also be a solution.