IPVS下CoreDNS滚动更新造成的解析失败问题优化

共计 1667 个字符，预计需要花费 5 分钟才能阅读完成。

IPVS 模式下，当 coredns 滚动更新期间，集群监控日志出现大量的连接超时，由于日志异常的时间和 coredns 变更时间完全重叠，怀疑是 coredns 滚动更新造成，下面进行问题复现，并给出优化方案。

实验

• 创建一个由 2 个 POD 作为后端的 coredns service
• 通过创建大量 DNS 查询来访问此服务
• 触发滚动更新 coredns

顺序查询

while true;do time (dig +tries=1 -4 +short A <name> @<dns clusterIP> >> dig.log) >> dig.log 2>&1;done

可以看到在 顺序执行（非并发压测）的情况下，已经出现较多DNS解析超时的情况

并发查询

dnsperf是一个开源的DNS压力测试工具，用户可以用它来对DNS服务器或者Local DNS做压力测试。dnsperf目前的实现是单进程模式，通过epoll非阻塞地处理网络事件

$ echo "www.srelife.cn A" > dnstest
$ dnsperf -d dnstest -s <DNS的IP> -c100000 -Q100000 -l60

优化

通过查阅 issue 得知，这里可能与ipvs_udp_timeout有关，默认的设置的是300s，coredns 滚动更新的时候 ipvs 中 udp 老链接会 300s 才删除，如果在 300s 内客户端有端口重用的话就会出现这个问题，并且这个时间和日志发生的时间也很类似，持续了5分钟。

优化改动

1. kube-proxy 加了ipvs-udp-timeout=10s

      spec:
        containers:
        - args:
          - --kubeconfig=/var/lib/kube-proxy/config
          - --hostname-override=$(NODE_NAME)
          - --v=2
          - --proxy-mode=ipvs
          ...
          - --ipvs-udp-timeout=10s

2. 等待5分钟（关键！！）

3. coredns configmap 中 health lameduck配置改成20s

   Corefile: |-
      .:53 {
          errors
          health {
              lameduck 20s
          }
          ready
   ...
   }

4. 查看 coredns日志，等待 reload

   

修改 coredns configmap 后，coredns 会自动 Reload，Relaod 过程中打印输出的 lameduck 时间为 上次配置的时间

优化后结果

可以看到，效果还是很明显的～

最后附上 dnspref 工具的常用参数：

Dnsperf 支持下面的这些命令行参数:
-s     用来指定DNS服务器的IP地址，默认值是127.0.0.1
-p     用来指定DNS服务器的端口，默认值是53
-d     用来指定DNS消息的内容文件，该文件中包含要探测的域名和资源记录类型，见下文
-t     用来指定每个请求的超时时间，默认值是3000ms
-Q     用来指定本次压测的最大请求数，默认值是1000
-c     用来指定并发探测数，默认值是100. dnsperf会从-d指定的文件中随机选取100个座位探测域名来发送DNS请求.
-l     用来指定本次压测的时间，默认值是无穷大。
-e     本选项通过EDNS0，在OPT资源记录中运用edns-client-subnet来指定真实的client ip. 
-i     用来指定前后探测的时间间隔，因为dnsperf是一个压测工具，所以本选项目前还不支持。
-P     指定用哪个传输层协议发送DNS请求，udp或者tcp。默认值是udp
-f     指定用什么地址类型发送DNS请求，inet或者inet6。默认值是inet
-v     除了标准的输出外，还输出每个相应码的个数。
-h     打印帮助

参考文档

https://github.com/kubernetes/kubernetes/issues/71514