之前章节我们通过service创建把mysql和wordpress分别部署到cluster上的节点中，他们之间是通过一个overlay网络进行基于serviceName通信的

DNS服务发现

DockerCompose的底层是基于DNS Server来相互通信的，而Swarm里面节点的通信也是基于此机制

如果某个service连接到overlay网络上，那么就会为该service增加一条DNS记录，这样基于此记录就可以知道service对应的IP地址。

注意service在DNS记录中的IP地址，并不是该service所在节点的IP地址，而是一种虚拟IP-VIP，你可以想象一下，service是支持横向扩展的，节点上需要灵活支持增加和移除service，如果在DNS里面通过容器节点地址标志，这个是很不稳定的，因为他一直在变的，而分配的VIP则是不变的，只不过映射的实际IP是会变的。

实验验证

创建overlay网络和对应service

这里首先创建一个名为demo的overlay网络。

然后创建一个service，基于whoami，这是一个web服务，返回容器的hostname：

docker service create --name whoami -p 8000:8000 --network demo -d jwilder/whoami

然后看一下service运行哪里：

尝试访问一下：

接着我们创建第二个service，busybox，并执行一个shell命令：

这个service位于worker1节点，接着我们进入这个busybox容器中：

service的ping通信尝试

接着我们在容器内部ping一下之前whoami：

我们ping whoami是可以通的，ping的ip是10.0.0.7，目前是可以访问到这个whoami-service，这里我们想要研究一下这个10.0.0.7是不是那个节点的ip地址呢？根据之前讨论的原理肯定不是的。

横向扩展再进行ping尝试

接着我们尝试横向扩展whoami，再去ping，地址会变吗？

我们直接实验一下，首先通过scale命令扩展一下：

docker service scale whoami=2

一个service在worker2，还有一个在manager，扩张了两个容器。

接着我们回去worker1节点，继续pingwhoami：

我们发现还是可以ping通，而且ip地址没变，这其实因为这个10.0.0.7是一个vip，虚拟IP，并不是任何一个节点的真实地址。

DNS查询

这里我们可以通过一个nslookup命令（mac下）查询一下DNS信息：

我们可以看到慕课网对应的IP地址有3个，接着我们在worker1节点中进入busybox容器中，在里面运行nslookup，查一下whoami：

这里我们是针对swarm维护的dns服务器查询，返回的是whoami的ip地址 --- 10.0.0.7。接着我们去manager和worker2节点，分别进入容器中运行ip -a查看一下，这里结果都没有发现10.0.0.7这个IP地址。

这里我们回到之前的busybox，重新查tasks.whoami的IP地址：

这里的两个地址其实就是whoami真正的IP地址

尝试访问whoami

这里我们发现多次访问同一个web服务，返回的hostname变了，不一定都是同一个值，这就是因为我们其实有3个whoami容器在给你服务，每次响应的whoami是不一样的，这里就是有一个负载均衡的处理在里面。

10.0.0.7背后对应了3个Web服务器，进行了load-banlance

总结 - RoutingMesh技术

这节课主要讲的是第一种，通过连接同一个overlay基于servcieName和VIP来进行通信的。

第二个ingress网络，如果service有绑定端口，例如8000端口，可以在swarm上任何节点进行访问。

这里继续看一下这节课内容：

在一个client访问一个swarm节点时候，通过DNS把service解析成一个VIP，然后通过LVS和iptables做一个负载均衡，把请求分配到不同节点上面去

本文正在参加「金石计划 . 瓜分6万现金大奖」