免费资源部落

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

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

实验

创建一个由 2 个 POD 作为后端的 coredns service

通过创建大量 DNS 查询来访问此服务

触发滚动更新 coredns

顺序查询whiletrue;dotime(dig+tries=1-4+shortA<name>@<dnsclusterIP>>>dig.log)>>dig.log2>&1;done

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

并发查询

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

$echo"www.mervinwang.comA">dnstest$dnsperf-ddnstest-s<DNS的IP>-c100000-Q100000-l60数据\解析超时时间1000ms500mssent6742340925completed6435834519lost3065 (4.55%)6406 (15.65%)优化

通过查阅 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{errorshealth{lameduck20s}ready...}

查看 coredns日志，等待 reload

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

优化后结果数据类型\解析超时时间1000ms500mssent8502780502completed8493080423lost97 (0.11%)79 (0.10%)

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

最后附上 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来指定真实的clientip.-i用来指定前后探测的时间间隔，因为dnsperf是一个压测工具，所以本选项目前还不支持。-P指定用哪个传输层协议发送DNS请求，udp或者tcp。默认值是udp-f指定用什么地址类型发送DNS请求，inet或者inet6。默认值是inet-v除了标准的输出外，还输出每个相应码的个数。-h打印帮助

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