运行容器,注意这里一定要带--privileged 否则后面的部分 tc 命令无法执行:
$ sudo docker run -d --privileged --name ctn-1 alpine:3.8 sleep 3600d $ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 233bc36bde4b alpine:3.8 "sleep 3600d" 1 minutes ago Up 14 minutes ctn-1进入容器:
$ sudo docker exec -it ctn-1 sh查看容器网络信息:
/ # ifconfig eth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:09 inet addr:172.17.0.9 Bcast:0.0.0.0 Mask:255.255.0.0查看 DNS 配置
Linux 上的 DNS 配置在/etc/resolv.conf 里面。我们先来查看容器的配置:
/ # cat /etc/resolv.conf# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 192.168.1.11 nameserver 192.168.1.12这其实是继承了宿主机的 DNS 配置,在宿主机上执行 cat /etc/resolv.conf 会看到一样的 结果
DNS 问题排查有时新启动的机器(不管是物理机、虚拟机还是容器)没有设置 DNS,导致访问域名不通。 我们来复现一下。
在正常的容器里用 nslookup 工具查看域名对应的 IP 地址:
/ # nslookup example.com Name: example.com Address 1: 93.184.216.34 Address 2: 2606:2800:220:1:248:1893:25c8:1946可以看到,我们获取到了该域名一个 IPv4 地址和一个 IPv6 地址。
将/etc/resolv.conf 里的 DNS 服务器列表用#注释掉,模拟没有配置 DNS 服务器的场景。
再次测试:
/ # nslookup example.com nslookup: cant resolve example.com: Try again所以遇到这种问题,可以先去排查/etc/resolv.conf 里面是否配置了 DNS 服务器
每个公司一般都有自维护的 DNS 服务器,不仅用来解析内网 DNS,而且可以加速解析公网域名 。
dig 是另外一个功能更强大的 DNS 查询工具,安装:
/ # apk update && apk add bind-tools首先查看使用内网 DNS,查询域名的延迟:
/ # dig example.com ... example.com. 15814 IN A 93.184.216.34 ;; Query time: 0 msec ;; SERVER: 192.168.1.11#53(192.168.1.11)可以看到非常快,在 1ms 以内。
然后我们测试如果使用 Google 的公网 DNS 服务器 8.8.8.8 [1],延迟会是多少。
修改/etc/resolv.conf,将其他 nameserver 注释掉,添加一行 nameserver 8.8.8.8。
再次测试:
/ # dig example.com ... example.com. 15814 IN A 93.184.216.34 ;; Query time: 120 msec ;; SERVER: 8.8.8.8#53(8.8.8.8)延迟变成了 150ms,比原来大了 150 多倍。
因此,对于 DNS 查询特别慢的场景,首先要查看配置的 DNS 服务器是否合理
前面提到,大部分公网域名都对应多个 IP 地址,因此每次 DNS 查询拿到的 IP 地址都可能不一 样,我们用 ping 来测试一下:
/ # ping baidu.com PING baidu.com (220.181.57.216): 56 data bytes 64 bytes from 220.181.57.216: seq=0 ttl=45 time=26.895 ms 64 bytes from 220.181.57.216: seq=1 ttl=45 time=26.701 ms ^C / # ping baidu.com PING baidu.com (123.125.115.110): 56 data bytes 64 bytes from 123.125.115.110: seq=0 ttl=43 time=27.587 ms 64 bytes from 123.125.115.110: seq=1 ttl=43 time=27.757 ms ^C可以看到,两次 ping 测试(内部首先查询 baidu.com 对应的 IP 地址)拿到的 IP 地址是不一样 的。用 nslookup 可以看到它们都是 baidu.com 对应的 IP 地址:
/ # nslookup baidu.com Name: baidu.com Address: 220.181.57.216 Name: baidu.com Address: 123.125.115.110/etc/hosts 里面可以直接 harcode 一个域名对应的 IP 地址,这会导致机器跳过 DNS 查询,直接拿这个 IP 作 为该域名的 IP。我们来验证一下。
修改/etc/hosts,添加一行 123.125.115.110 baidu.com,再次 ping 测试
/ # ping baidu.com PING baidu.com (123.125.115.110): 56 data bytes 64 bytes from 123.125.115.110: seq=0 ttl=43 time=27.861 ms ^C --- baidu.com ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 27.861/27.861/27.861 ms / # ping baidu.com PING baidu.com (123.125.115.110): 56 data bytes 64 bytes from 123.125.115.110: seq=0 ttl=43 time=27.614 ms ^C这是不管执行多少次,baidu.com 对应的 IP 地址都不会变了。而实际上,这个 IP 地址并不一定是最优的 IP 地址,甚至有可能这 个 IP 不可用,导致访问 baidu.com 失败
我们用 tc 来模拟网络延迟:
/ # apk add iproute2首先查看有没有 tc 规则:
/ # tc -p qdisc ls dev eth0默认没有任何规则。
然后我们加一条:每个 packet 延迟 600ms:
/ # tc qdisc add dev eth0 root netem delay 600ms / # tc -p qdisc ls dev eth0 / # qdisc netem 8001: root refcnt 2 limit 1000 delay 600.0ms测试:
/ # dig example.com ... example.com. 15814 IN A 93.184.216.34 ;; Query time: 600 msec ;; SERVER: 192.168.1.11#53(192.168.1.11)可以看到,DNS 查询变成了 600ms。
这里我们测试的是固定延迟,这种问题很容易发现。我们还可以测试随机延迟,或者按 比例延迟等 [2]:
/ # tc qdisc change dev eth0 root netem delay 600ms 10ms 25% / # tc qdisc change dev eth0 root netem delay 600ms 20ms distribution normal此类规则会导致 DNS 查询速度更有随机性。
最后删除 tc 规则:
/ # tc qdisc del dev eth0 rootiptables 规则也会导致类似的问题。
很多软件在运行之后,会在宿主机上添加 tc 或 iptables 规则,例如 OpenStack,K8S 等等 。因此遇到这种随机延迟问题,首先可以查看机器上是否有 tc 或 iptables 规则
线上遇到过这样一个问题:从一台机器 ping 一个内网域名,每个 ping 包看起来都会卡 5~30s 不等,但是 CTL-C 关闭 ping 之后,打印出来的统计信息里,既没有丢包,ping 的延迟也很低 (毫秒级),这就很奇怪。接下来:
dig <URL>,很快,毫秒级,说明 DNS 查询没有问题dig 能看到域名对应的 IP,直接 ping 这个 IP,发现是没有卡顿的仍然 ping 域名,用 tcpdump 抓包,tcpdump -i eth0 host <URL> and icmp,发现 ping 包都是立即响应的,印证了统计信息里,ping 延迟很低的事实根据以上信息,说明 ping 卡顿的问题出在这台机器,而且应该就是 ping 程序本身在做什么耗 时的操作。继续:
仍然 ping 域名,同时,用 ltrace -p <PID>跟踪 ping 进程,发现卡在一个叫 gethostbyaddr()的函数查阅文档,发现这个函数是根据 IP 反向查询 hostname,需要和 DNS 交互到这里,基本确定了是 DNS 服务器反向查询的问题,我们用另外几个命令行工具验证一下, 以下三个命令都是根据 IP 反查 hostname:
nslookup <IP>host <IP>dig -x <IP>果然,以上三个命令都会卡住。修改/etc/resolv.conf,换一个 DNS 服务器之后,问题 消失了。
相关标签: