「【只做懂你de云原生干货知识共享】」
Kubernetes中coredns查询记录
工作中我遇到coredns的相关错误性问题很多，很多都是用户那边在使用k8s当中，或者调试当中遇到的一些错误性问题，这里会有一些总结，另外对于它的解析查询记录原理是作为一名前线人员是一项必备技能，遇到问题如何解决我们要懂它的原理以及解析过程中的记录查询是怎样流转的，如果知道这些对我们排查过程会起很大的帮助。
我之前还分享一篇coredns 5s延迟以及如何利用缓存cache来提升dns命中率的文章，对于这些我还遇到了，在pod当中外部内部dns都解析失败的情况，或者说外部有时可以解析到，有时候解析不到，或者解析外部域名有时可以，有时不可以，内部解析正常，或者说内部外部都可以，但是cache解析非常慢，～～～，相信你现在已经无从下手了
理解内部的原理相信你可以很快上手工作中那些非常棘手的dns问题
在Kubernetes中部署工作负载的主要优势之一是无缝应用程序发现。服务的概念使群集内通信变得容易，服务的概念代表了支持一组Pod IP的虚拟IP。例如，如果vanilla服务需要与服务对话chocolate，则可以将Virtual IP直接用于chocolate。现在的问题是谁解决DNS查询chocolate以及如何解决？
DNS解析是通过CoreDNS在Kubernetes集群中配置的。kubelet将每个Pod配置/etc/resolv.conf为使用coredns pod作为nameserver。你可以看到/etc/resolv.conf任何pod内部的内容，它们的外观类似于：
DNS客户端使用此配置将DNS查询转发到DNS服务器。resolv.conf是解析器配置文件，其中包含以下信息：
nameserver：将DNS查询转发到的位置。在我们的情况下，这是CoreDNS服务的地址。
search：表示特定域的搜索路径。有趣的是google.com还是mrkaran.dev不是FQDN（完全合格的域名）。大多数DNS解析器都遵循的标准约定是，如果域以.（表示根区域）结尾，则该域被视为FQDN。一些解析器尝试采取明智的行动并.自我补充。mrkaran.dev.FQDNmrkaran.dev也是如此，但事实并非如此。
ndots：这是最有趣的值，也是本文的重点。ndots表示查询名称中点数的阈值，以将其视为“完全合格”域名。稍后，我们会发现DNS查找的流程。
让我们检查一下mrkaran.dev在Pod中查询时会发生什么。
对于此实验，我还打开了CoreDNS日志记录级别all，使其变得非常冗长。让我们看一下corednspod的日志：
[INFO] 10.1.28.1:35998 - 11131 "A IN mrkaran.dev.hello.svc.cluster.local. udp 53 false 512" NXDOMAIN qr,aa,rd 146 0.000263728s
[INFO] 10.1.28.1:34040 - 36853 "A IN mrkaran.dev.svc.cluster.local. udp 47 false 512" NXDOMAIN qr,aa,rd 140 0.000214201s
[INFO] 10.1.28.1:33468 - 29482 "A IN mrkaran.dev.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000156107s
[INFO] 10.1.28.1:58471 - 45814 "A IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 56 0.110263459s
[INFO] 10.1.28.1:54800 - 2463 "AAAA IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 68 0.145091744s
所以有两件事引起了我的兴趣：
该查询将遍历所有搜索路径，直到答案包含一个NOERROR代码（DNS客户端将其理解并存储为结果）。NXDOMAIN仅表示未找到该域名的记录。由于mrkaran.dev不是FQDN（根据ndots=5设置），因此解析程序会查看搜索路径并确定查询顺序。
A并AAAA并行触发记录。这是因为single-requestin选项/etc/resolv.conf具有默认配置以执行并行IPv4和IPv6查找。您可以禁用此使用single-request选项。
注意：glibc可以配置为按顺序发送这些请求，但是musl不能发送，因此Alpine用户必须注意。
玩ndots
让我们再玩ndots一点，看看它的表现。这个想法很简单，DNS客户端通过此ndots设置可以知道一个域是否是绝对的。例如，如果您google简单地查询，DNS客户端将如何知道这是否是绝对域。如果设置ndots为1，则DNS客户端会说“哦，google甚至没有一个1点。让我尝试遍历搜索列表。但是，如果您查询google.com，则搜索列表将被完全忽略，因为查询名称满足ndots阈值（至少一个点）。
我们可以通过实际操作看到它：
$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10#53
** server can't find mrkaran: NXDOMAIN
CoreDNS日志：
[INFO] 10.1.28.1:52495 - 2606 "A IN mrkaran.hello.svc.cluster.local. udp 49 false 512" NXDOMAIN qr,aa,rd 142 0.000524939s
[INFO] 10.1.28.1:59287 - 57522 "A IN mrkaran.svc.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000368277s
[INFO] 10.1.28.1:53086 - 4863 "A IN mrkaran.cluster.local. udp 39 false 512" NXDOMAIN qr,aa,rd 132 0.000355344s
[INFO] 10.1.28.1:56863 - 41678 "A IN mrkaran. udp 25 false 512" NXDOMAIN qr,rd,ra 100 0.034629206s
由于mrkaran未指定任何内容，.因此使用搜索列表来查找答案。
ndots值静默限制为15,Kubernetes默认值为5。
在生产中处理
如果你的应用程序具有进行大量外部网络调用的性质，那么在流量繁忙的情况下，DNS可能会成为瓶颈，因为在触发真正的DNS查询之前还会进行很多额外的查询。看到应用程序在域名中附加根区域的情况很少见，因此，无需使用api.twitter.com，你可以对应用程序进行硬编码以使其包含在内api.twitter.com.，这将迫使DNS客户端直接在绝对域上进行权威性查找。
或者，自K8s 1.14起，dnsConfig和dnsPolicy门和特征已变得稳定。因此，在部署pod时，你可以将ndots设置指定为较小的内容，例如，3或者为1。这样的后果将是现在每个节点内通信都必须包含整个域。这是经典的权衡之一，你必须在性能和可移植性之间进行选择。如果应用程序不需要极低的延迟，我想你根本就不必担心这一点，因为你还可以选择更优的cache来实现
排查小工具dnstools
最后你还可以安装一个带有nslookup、dig的dnstools排查工具，方便你在工作当中使用它。
kubectl run -it --rm --restart=Never --image=infoblox/dnstools:latest dnstools sh
参考地址：https://mrkaran.dev/posts/ndots-kubernetes/
盛年不重来，一日难再晨。及时宜自勉，岁月不待人。「——陶渊明」。
【一个懂你的云原生知识共享平台】
「欢迎扫描下方二维码关注」
