我们正在运行6个引擎的环境，每个引擎有30个容器。 两个引擎正在使用nginx代理运行容器。这两个容器是进入网络的唯一途径。
这是我们第二次在这种环境下面对一组容器的主要问题：
两个Nginx容器都无法到达其他计算机上的某些容器。只有一个物理引擎有此问题，其他所有都很好。从某些计算机超时开始，到24小时后，该计算机上的所有容器都出现了问题。
更多详细信息：
Nginx在机器prod-3上运行。 第二个Nginx在机器prod-6上运行。 有问题的容器在prod-7上运行。 两个nginx都无法到达容器，但是容器可以通过“ ping”到达nginx。
在开始和今天早晨，我们可以到达一些集装箱，而其他则没有。它从超时开始，现在我们无法ping覆盖网络中的容器。这次我们可以使用tcpdump查看流量：
在Nginx容器（prod-3上为10.10.0.37）上，我们开始ping并 如您所见：100％数据包丢失：
root@e89c16296e76:/# ping ew-engine-evwx-intro
PING ew-engine-evwx-intro (10.10.0.177) 56(84) bytes of data.
--- ew-engine-evwx-intro ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7056ms
root@e89c16296e76:/#
在目标机器prod-7上（不在容器内）-我们看到所有ping包都已收到（因此覆盖网络正确路由到prod-7）：
wurzel@rv_____:~/eventworx-admin$ sudo tcpdump -i ens3 dst port 4789 |grep 10.10.0.177
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 10.10.0.37.35270 > 10.10.0.177.http: Flags [S], seq 2637350294, win 28200, options [mss 1410,sackOK,TS val 1897214191 ecr 0,nop,wscale 7], length 0
IP 10.10.0.37.35270 > 10.10.0.177.http: Flags [S], seq 2637350294, win 28200, options [mss 1410,sackOK,TS val 1897214441 ecr 0,nop,wscale 7], length 0
IP 10.10.0.37.35326 > 10.10.0.177.http: Flags [S], seq 2595436822, win 28200, options [mss 1410,sackOK,TS val 1897214453 ecr 0,nop,wscale 7], length 0
IP 10.10.0.37 > 10.10.0.177: ICMP echo request, id 83, seq 1, length 64
IP 10.10.0.37.35326 > 10.10.0.177.http: Flags [S], seq 2595436822, win 28200, options [mss 1410,sackOK,TS val 1897214703 ecr 0,nop,wscale 7], length 0
IP 10.10.0.37 > 10.10.0.177: ICMP echo request, id 83, seq 2, length 64
IP 10.10.0.37 > 10.10.0.177: ICMP echo request, id 83, seq 3, length 64
IP 10.10.0.37 > 10.10.0.177: ICMP echo request, id 83, seq 4, length 64
IP 10.10.0.37 > 10.10.0.177: ICMP echo request, id 83, seq 5, length 64
IP 10.10.0.37 > 10.10.0.177: ICMP echo request, id 83, seq 6, length 64
IP 10.10.0.37 > 10.10.0.177: ICMP echo request, id 83, seq 7, length 64
IP 10.10.0.37 > 10.10.0.177: ICMP echo request, id 83, seq 8, length 64
^C304 packets captured
309 packets received by filter
0 packets dropped by kernel
wurzel@_______:~/eventworx-admin$
起初-您会看到没有有效的ICMP（防火墙不负责任，也不负责任）。
在负责任的容器（evwx-intro = 10.10.0.177）内什么也没收到，接口eth0（10.10.0.0）只是静默：
root@ew-engine-evwx-intro:/home/XXXXX# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
root@ew-engine-evwx-intro:/home/XXXXX#
真的很奇怪。
泊坞窗上的其他任何工具都可以帮助我们了解发生了什么情况？
我们没有对防火墙进行任何更改，也没有对系统进行自动更新（也许是安全性）。
唯一的活动是，一些旧的容器经过很长一段时间（可能是1-2个月的不活动）已被重新激活。
我们真的迷失了，如果您经历了类似的事情，那么了解您所采取的步骤将非常有帮助。
非常感谢您对此提供的帮助。
================================================ =============
在尝试了一整天的几乎所有内容之后，我们进行了最后的尝试： （1）停止所有容器 （2）停止docker服务 （3）停止docker socket服务 （4）重启机器 （5）启动容器
...现在看起来不错。 结论： （1）我们不知道是什么导致了问题。这是不好的。 （2）我们了解到覆盖网络不是问题，因为流量正在到达容器所在的目标机器 （3）我们能够跟踪网络流量，直到它到达目标计算机为止。不知何故，它不是“进入”容器。因为在容器内部，网络接口根本不显示任何活动。
我们对docker使用的vxnet虚拟网络一无所知，因此，如果有人有提示，您能帮我们提供有关它的链接或工具吗？
非常感谢。 安德烈
================================================ ======= 4天后...
在将docker-ce 18.06更新为18.09之后，再次具有相同的情况。
我们有两台将docker-ce 18与ubuntu 18.04结合使用的机器，由于这个问题，我刚刚将docker-ce更新为18.09（Docker容器不应在Ubuntu 18.04中解析DNS ...新的已解析服务）。 / p>
我停止了所有机器，更新了docker，重新启动了机器，启动了所有机器。
问题：与本帖子中描述的问题相同。 ping被目标主机操作系统接收到，但没有转发到容器。
解决方案： 1.停止所有容器和泊坞窗 2.领事假， 3.清理其他计算机上领事密钥库中的所有条目（未通过请假删除） 3.开始领事 4.重新启动所有引擎 5.重新启动nginx容器...陷阱，网络正在工作。
答案 0 :(得分：0)
同样的问题再次困扰着我们。 我们有7个服务器（每个服务器都如上所述运行docker）和两个nginx入口点。
看起来，领事密钥存储区中的一些错误是导致docker网络显示出奇怪行为的真正问题（如上所述）。
在我们的配置中，所有7台服务器都有自己的本地领事实例，这些实例与其他服务器同步。对于网络设置，每个docker服务都在其本地领事密钥存储区进行查找。
在上周，我们注意到在网络可达性问题的同时，领事客户也报告了同步问题（领导者选举问题，重复等）。
最终的解决方案是停止docker引擎和领事客户端。删除某些服务器上的领事数据库，然后将其再次加入其他服务器。启动Docker引擎。
看起来领事服务是网络配置的关键部分...
进行中...
答案 1 :(得分：0)
我遇到了覆盖网络Docker Swarm设置的确切问题。 我发现这不是操作系统或Docker问题。受影响的服务器正在使用Intel NIC X系列。其他具有I系列NIC的服务器运行正常。 您是否使用本地服务器？还是任何云提供商？ 我们使用OVH，这可能是由于某些数据中心网络配置错误所致。