云浮 网站建设,vultr做网站,网站招聘方案怎么做,3g门户 手机上网第一门户一、Linux DNS查询解析原理#xff08;对于调用glibc库函数gethostbyname的程序#xff09;我们在浏览器访问www.baidu.com这个域名#xff0c;dns怎么查询到这台主机呢#xff1f; 1、在浏览器中输入www.baidu.com域名#xff0c;操作系统会先查找本地DNS解析器缓存对于调用glibc库函数gethostbyname的程序我们在浏览器访问www.baidu.com这个域名dns怎么查询到这台主机呢 1、在浏览器中输入www.baidu.com域名操作系统会先查找本地DNS解析器缓存nscd是否有这个网址映射关系如果有直接返回完成域名解析。 2、如果本地DNS解析器缓存nscd里没有这个域名的映射或是没有安装nscd服务则通过/etc/nsswitch.conf中的hosts配置项来决定域名查询获取顺序。 通常该配置项为hosts: files dns myhostname则表示先读/etc/hosts否则就读/etc/resolv.conf向DNS服务器发出域名解析请求。 3、如果本地DNS解析器缓存与/etc/hosts都没有相应的网址映射关系首先会找/etc/resolv.conf中设置的第一个DNS服务器在此我们叫它本地DNS服务器 此服务器收到查询时如果要查询的域名包含在本地配置区域资源中则返回解析记过给客户端完成域名解析此解析具有权威性。 4、如果要查询域名不由本地DNS服务器区域解析但该服务器已缓存了此网址映射关系则调用这个IP地址映射完成域名解析此解析不具有权威性。 5、如果本地DNS服务器本地区域文件与缓存解析都失效则根据本地DNS服务器的设置是否设置转发器进行查询如果未用转发模式本地DNS就把请求发至13台根DNS根DNS服务器收到请求后会判断这个域名.com是谁来授权管理并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后如果自己无法解析它就会找一个管理.com域的下一级DNS服务器地址baidu.com给本地DNS服务器。当本地DNS服务器收到这个地址后就会找baidu.com域服务器重复上面的动作进行查询直至找到www.baidu.com主机。 6、如果用的是转发模式此DNS服务器就会把请求转发至上一级DNS服务器由上一级服务器进行解析上一级服务器如果不能解析或找根DNS或把请求转至上上级以此循环。不管是本地DNS服务器用是转发还是根提示最后都是把结果返回给本地DNS服务器由此DNS服务器再返回给客户机。 二、K8S DNS解析过程1、node节点VMDNS解析(1) ping www.baidu.com --Node上 local DNS cache(Linux nscd服务如果有DNS缓存服务的情况否则跳过) -(2) Node上/etc/hosts文件 -(3) DNS Server(Node上/etc/resolv.conf中记录的nameserver一般是按顺序取第一个 ) -(4) DNS Server Cache -(5) 如果第一个上游DNS Server没查到那么该DNS Server转发给上一级DNS Server或根DNS Server以此循环2、K8S Pod DNS解析(1) pingwww.baidu.com - Pod的容器里 local DNS cache(一般情况下容器镜像不会安装Linux nscd服务这里跳过) -(2) Pod的容器里/etc/hosts文件-例如测试Pod对应容器里的 /etc/hosts(3) CoreDNS(Pod的容器里/etc/resolv.conf中记录的nameserver一般这里Pod dnsPolicy策略默认设置的是ClusterFirst所以该nameserver为CoreDNS的Cluster IP )-例如测试Pod对应容器里的 /etc/resolv.conf, 这里的10.0.248.10为CoreDNS的Cluster IP下图是对应CoreDNS的Service信息(4) CoreDNS CacheCoreDNS cache插件该插件会缓存已经查询过的DNS解析的信息见下图的cache字段-(5) 如果CoreDNS没查到(一般只提供了kubernetes集群内的部域名的解析具体是CoreDNS kubernetes插件)那么CoreDNS可以通过forward内置见上图中的forward字段或proxy插件第三方单独提供转发给上游DNS Server。当然forward插件可配置查找当前容器内的/etc/resolv.conf文件的nameserver配置可写为forward . /etc/resolv.conf注意CoreDNS的Pod dnsPolicy策略为Default所以/etc/resolv.conf文件内容与node节点保持一致如下三、参考文献https://www.cnblogs.com/zhangxingeng/p/9970733.htmlhttps://coredns.io/plugins/https://coredns.io/manual/toc/https://github.com/coredns/proxyhttps://kubernetes.io/docs/concepts/services-networking/dns-pod-service/https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/#corednsK8S DNS 5s延迟问题说明一、问题复现环境k8s托管集群版本1.14k8s node镜像系统centos 7.4/7.6node内核版本3.10.xxx二、问题描述1.客户在k8s node上做curl请求(没有dns缓存)经常有响应时间达到5秒以上的请求。2.客户在k8s pod上做curl请求(没有dns缓存)经常有响应达5s以上的请求。命令行 curl -o /dev/null -s -w time_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_nslookup:%{time_namelookup}\ntime_total: %{time_total}\n https://api.weixin.qq.com三、问题定位问题1(1)使用curl命令行做测试问题概率性复现10%左右。(2)使用dig 命令行做测试 dig api.weixin.qq.com 问题概率性复现。(3)tcpdump在node上抓包分析结合wireshark做分析发现DNS客户端通过UDP协议并发查询A记录(ipv4)和AAAA记录(ipv6)并且使用了相同五元组但是有AAAA记录未收到的情况。 当AAAA记录未收到时即产生了5s左右的延迟。通过查询文档发现dns请求默认超时时间为5s。(4)SDN侧定位发现没有丢包丢包位置为内核协议栈。(5)内核侧定位认为丢包是由内核协议栈contrack模块bug导致的。触发条件为UDP使用相同五元组做并发请求时。参见:https://cloud.tencent.com/developer/article/1449227https://www.weave.works/blog/racy-conntrack-and-dns-lookup-timeouts4.19以上内核合入了修复patch。问题2定位方式及原因同1。四、解决方案1.规避方案并发dns请求使用不同的源端口来避免内核收包冲突。对于node在resolv.conf中增加options single-request-reopen。对于pod在pod yaml中添加dns配置需要客户侧自己管理配置。 template: spec: dnsConfig: options: - name: single-request-reopen
