dockerswarm 容器链接：“tasks.service1”与直接“service1”

Question

When using a docker swarm, what is the difference between using "tasks.service1" or directly "service1" when curling/pinging?

Practical exemple: i start a docker swarm with a service on the same overlay network as follow:

$> docker network create --driver=overlay public
$> docker service create --name service1 --replicas=2 --network public ubuntu sleep 10000

now i list containers:

$> docker ps -a
bd645378cb2d   ubuntu:latest   "sleep 10000"   43 seconds ago   Up 41 seconds             service1.1.rjy91s66col81libdilrd698j
686c0ab006fc   ubuntu:latest   "sleep 10000"   43 seconds ago   Up 41 seconds             service1.2.wjrwsj6h6rcadsknzxym4h9w0

if i attach to the first container i can ping the others:

$> docker exec -ti bd645378cb2d bash
$> apt update
$> apt install iputils-ping dnsutils
$> ping service1 # returns ok 10.0.1.65

when i dig the special hostname tasks.service1 i get all replicas ips. but theses do not match with the one i get with ping.

$> dig tasks.service1 # returns 10.0.1.66 & 10.0.1.67

Why do ips doesn't match? if i need to connect to service 2 from service 1, should i use tasks.service2 or service2?

Answer 1

This is a load-balancer IP. Docker service has it if created with default vip (Virtual IP) --endpoint-mode . You can see it with docker inspect <service_name> :

"Endpoint": {
    "Spec": {
        "Mode": "vip"
    },
    "VirtualIPs": [
        {
            "NetworkID": "i7k7pv9s4v7dgvc57zjmh6pk6",
            "Addr": "10.0.1.2/24"
        }
    ]
}

This is mentioned in the documentation , although it is easy to miss the point:

To use an external load balancer without the routing mesh, set --endpoint-mode to dnsrr instead of the default value of vip . In this case, there is not a single virtual IP.

Answer 2

The tasks.service1 name will resolve to the IP addresses of each individual container in the service. This can be useful if you need to reference individual replicas.

However, there's a downside. DNS caches in most OSs and applications. That means during an update to your service, the stale DNS resolution may point to an IP that is no longer reachable, or could point to an entirely different container that was recently started with a recycled IP.

To handle this in Swarm Mode, a virtual IP (VIP) is the default when resolving service1 . This is dynamically updated as replicas are created/deleted without the issue of DNS caching. It performs a round robin load balancing on each new connection.

Side note, this is also used by the ingress on published ports. Which means you could end up with an extra network hop if you have an external LB pointing to the cluster, a port published on ingress, to a globally scheduled service. In those cases, I typically bypass the VIP, publish the port in host mode, and let the external LB direct requests to different nodes in the cluster.