IPVS下CoreDNS滚动更新解析失败原理是什么

这篇文章主要介绍了IPVS下CoreDNS滚动更新解析失败原理是什么的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇IPVS下CoreDNS滚动更新解析失败原理是什么文章都会有所收获，下面我们一起来看看吧。

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.mervinwang.com A" > dnstest$ dnsperf -d dnstest -s <DNS的IP> -c100000 -Q100000 -l60

优化

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

优化改动

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

等待5分钟（关键！！）

coredns configmap 中 health lameduck配置改成20s

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

查看 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     打印帮助

关于“IPVS下CoreDNS滚动更新解析失败原理是什么”这篇文章的内容就介绍到这里，感谢各位的阅读！相信大家对“IPVS下CoreDNS滚动更新解析失败原理是什么”知识都有一定的了解，大家如果还想学习更多知识，欢迎关注编程网行业资讯频道。