"tasks.service1“与"service1”之间的直接链接

Question

当使用码头群，使用"tasks.service1“或直接"service1”时卷发/敲打有什么区别？

实际示例:我在相同的覆盖网络上启动了一个带有服务的码头群，如下所示：

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

现在我列出集装箱：

$> 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

如果我附加到第一个容器，我可以平平其他的：

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

当我挖掘特殊的主机名tasks.service1时，我会得到所有副本ips。但是这些和我用ping得到的不匹配。

$> dig tasks.service1 # returns 10.0.1.66 & 10.0.1.67

为什么ips不匹配？如果我需要从服务1连接到服务2，我应该使用tasks.service2还是service2？

Answer 1

这是一个负载平衡器IP。如果使用默认的vip (Virtual ) --endpoint-mode创建Docker服务，则该服务具有此功能。你可以在docker inspect <service_name>上看到它

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

在文档中提到了这一点，尽管很容易忽略这一点：

若要使用没有路由网格的外部负载均衡器，请将端点模式设置为dnsrr，而不是vip的默认值。在这种情况下，没有一个虚拟IP。

Answer 2

tasks.service1名称将解析为服务中每个单独容器的IP地址。如果需要引用单个副本，这可能很有用。

然而，也有不利的一面。DNS缓存在大多数开放源码软件和应用程序中。这意味着在更新您的服务时，过时的DNS解析可能指向无法再访问的IP，或者指向最近使用循环IP启动的完全不同的容器。

要在群集模式中处理这个问题，在解析service1时默认使用虚拟IP (VIP)。在没有DNS缓存问题的情况下，创建/删除副本时会动态更新副本。它对每个新连接执行循环负载平衡。

附带注意，这也是在已发布的端口上的入口使用的。这意味着，如果有一个外部LB指向集群(入口上发布的一个端口)到一个全局调度服务，则可能会有一个额外的网络跳。在这些情况下，我通常绕过VIP，以主机模式发布端口，并让外部LB将请求直接发送到集群中的不同节点。