多余的DNS查询 一些需要解析外部DNS域名的应用，当运行在容器中时，如果我们在容器的network namespace中对dns报文（udp port 53）进行抓包，可能会发现在正确解析之前，还经过了若干次多余的尝试。
下面是我在容器中ping google.com，同时在容器的network namespace中抓到的包。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 sudo nsenter -t 3885 -n tcpdump -i eth0 udp port 53 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 10:09:11.917900 IP 10.244.2.202.38697 > 10.96.0.10.domain: 11858+ A? google.com.default.svc.cluster.local. (54) 10:09:11.918847 IP 10.96.0.10.domain > 10.244.2.202.38697: 11858 NXDomain*- 0/1/0 (147) 10:09:11.922468 IP 10.244.2.202.38697 > 10.96.0.10.domain: 15573+ AAAA? google.com.default.svc.cluster.local. (54) 10:09:11.923001 IP 10.96.0.10.domain > 10.244.2.202.38697: 15573 NXDomain*- 0/1/0 (147) 10:09:11.923248 IP 10.244.2.202.43230 > 10.96.0.10.domain: 62042+ A? google.com.svc.cluster.local. (46) 10:09:11.923828 IP 10.96.0.10.domain > 10.244.2.202.43230: 62042 NXDomain*- 0/1/0 (139) 10:09:11.924005 IP 10.244.2.202.43230 > 10.96.0.10.domain: 54769+ AAAA? google.com.svc.cluster.local. (46) 10:09:11.924494 IP 10.96.0.10.domain > 10.244.2.202.43230: 54769 NXDomain*- 0/1/0 (139) 10:09:11.924704 IP 10.244.2.202.36252 > 10.96.0.10.domain: 20727+ A? google.com.cluster.local. (42) 10:09:11.925154 IP 10.96.0.10.domain > 10.244.2.202.36252: 20727 NXDomain*- 0/1/0 (135) 10:09:11.925316 IP 10.244.2.202.36252 > 10.96.0.10.domain: 13066+ AAAA? google.com.cluster.local. (42) 10:09:11.925758 IP 10.96.0.10.domain > 10.244.2.202.36252: 13066 NXDomain*- 0/1/0 (135) 10:09:11.925929 IP 10.244.2.202.35582 > 10.96.0.10.domain: 38821+ A? google.com.lan. (32) 10:09:11.927244 IP 10.244.2.202.35582 > 10.96.0.10.domain: 4430+ AAAA? google.com.lan. (32) 10:09:11.927416 IP 10.96.0.10.domain > 10.244.2.202.35582: 38821 NXDomain 0/0/0 (32) 10:09:11.928600 IP 10.96.0.10.domain > 10.244.2.202.35582: 4430 NXDomain 0/0/0 (32) 10:09:11.928839 IP 10.244.2.202.45290 > 10.96.0.10.domain: 45577+ A? google.com. (28) 10:09:11.929129 IP 10.244.2.202.45290 > 10.96.0.10.domain: 37586+ AAAA? google.com. (28) 10:09:11.929303 IP 10.96.0.10.domain > 10.244.2.202.45290: 45577 1/0/0 A 172.217.160.78 (54) 10:09:11.929541 IP 10.96.0.10.domain > 10.244.2.202.45290: 37586 1/0/0 AAAA 2404:6800:4008:801::200e (66)
可以看到，在最后（倒数第3、4行）正确解析之前，先是依次查询了下面几个域名，并且均查询了IPv4和IPv6：
google.com.default.svc.cluster.local.google.com.svc.cluster.local.google.com.cluster.local.google.com.lan.
但是这8次查询都失败了，因为并不存在这样的域名。
kubernetes的容器域名解析 要想解释上面的现象，需要先从kubernetes的容器域名解析开始讲。
kubernetes上运行的容器，其域名解析和一般的Linux一样，都是根据 /etc/resolv.conf 文件。如下是容器中该文件的内容。
1 2 3 nameserver 10.96.0.10 search default.svc.cluster.local svc.cluster.local cluster.local lan options ndots:5
nameserver即为kubernetes集群中，kube-dns的svc IP，集群中容器的nameserver均设置为kube-dns。
1 2 3 kubectl get svc -n kube-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 236d
那么search和ndots是做什么的呢？
search和ndots 在解释search和ndots之前，需要先了解一个概念：FQDN(Fully qualified domain name)。
FQDN是完整域名，一般来说，域名最终以.结束表示是FQDN，例如google.com.是FQDN，但google.com不是。
对FQDN，操作系统会直接查询DNS server。那么非FQDN呢？这里就要用到search和ndots了。
ndots表示的是域名中必须出现的.的个数，如果域名中的.的个数不小于ndots，则该域名为一个FQDN，操作系统会直接查询；如果域名中的.的个数小于ndots，操作系统会在search搜索域中进行查询。
例如上面的例子，ndots为5，查询的域名google.com不以.结尾，且.的个数少于5，因此操作系统会依此在default.svc.cluster.local svc.cluster.local cluster.local lan四个域中进行了搜索，其中前面3个搜索域是由kubernetes注入的，最后的lan是操作系统默认的搜索域。
ndots默认值为1，也就是说，只要域名中有一个.，操作系统就会认为是绝对域名，直接查询。
ndots上限为15。
1 2 ndots:n Sets a threshold for the number of dots which must appear in a name given to res_query(3) (see resolver(3)) before an initial absolute query will be made. The default for n is 1, meaning that if there are any dots in a name, the name will be tried first as an absolute name before any search list elements are appended to it. The value for this option is silently capped to 15.
kubernetes为什么使用搜索域 为什么呢？先来看看代码。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 var ( defaultDNSOptions = []string {"ndots:5" } ) func (c *Configurer) string , pod *v1.Pod) []string { if c.ClusterDomain == "" { return hostSearch } nsSvcDomain := fmt.Sprintf("%s.svc.%s" , pod.Namespace, c.ClusterDomain) svcDomain := fmt.Sprintf("svc.%s" , c.ClusterDomain) clusterSearch := []string {nsSvcDomain, svcDomain, c.ClusterDomain} return omitDuplicates(append (clusterSearch, hostSearch...)) } func (c *Configurer) error ) { ... case podDNSCluster: if len (c.clusterDNS) != 0 { dnsConfig.Servers = []string {} for _, ip := range c.clusterDNS { dnsConfig.Servers = append (dnsConfig.Servers, ip.String()) } dnsConfig.Searches = c.generateSearchesForDNSClusterFirst(dnsConfig.Searches, pod) dnsConfig.Options = defaultDNSOptions break } ... if utilfeature.DefaultFeatureGate.Enabled(features.CustomPodDNS) && pod.Spec.DNSConfig != nil { dnsConfig = appendDNSConfig(dnsConfig, pod.Spec.DNSConfig) } }
kubernetes搜索域 从函数generateSearchesForDNSClusterFirst中可见，搜索域有三个：nsSvcDomain、svcDomain、clusterDomain。
kubernetes之所以要设置搜索域，目的是为了方便用户访问service。
例如，default namespace下的Pod a，如果访问同namespace下的service b，直接使用 b 就可以访问了，而这个功能，就是通过nsSvcDomain搜索域default.svc.cluster.local完成的。
类似的，对于不同namespace下的service，可以用 ${service name}.${namespace name} 来访问，是通过svcDomain搜索域完成的。
clusterDomain设计的目的，是为了方便同域中非kubernetes上的域名访问，例如设置kubernetes的domain为ieevee.com，那么对于s.ieevee.com域名，直接使用s来访问就可以了，当然前提是当前namespace中没有一个叫做s的svc。（是的。搜索域是有优先级的）
ndots默认值 ndots默认值是写死的，5。
为什么是5呢？
thockin在issue 33554 中做了解释，概况来说：
kubernetes需要支持同namespace下service快速访问，例如name，因此 ndots>=1，对应搜索域$namespace.svc.$zone
kubernetes需要支持跨namespace下service快速访问，例如kubernetes.default，因此 ndots>=2，对应搜索域svc.$zone
kubernetes需要支持同namespace、跨namespace下，非service名称的快速访问，例如name.namespace.svc，因此 ndots>=3，对应搜索域$zone
kubernetes需要支持statefulset中的每个pod的访问，例如mysql-0.mysql.default.svc，因此 ndots>=4
kubernetes需要支持SRV records（_$port._$proto.$service.$namespace.svc.$zone），因此 ndots>=5
不过呢，如果你的使用情况并不像上面这么复杂，这个值可能并不适合你。
比如说，我们只会用到同namespace下(形如 a)、跨namespace下的service访问（形如 a.b），因此，ndots默认值为2更合适，但该值是写死在代码中的，不支持定制化，但可以通过下面的方法修改。
ndots修改 ndots是可以被修改的，可以通过pod.Spec.DNSConfig改写。
1 2 3 4 5 6 7 8 9 10 11 12 13 apiVersion: v1 kind: Pod metadata: namespace: default name: dns-example spec: containers: - name: test image: nginx dnsConfig: options: - name: ndots value: "2"
通过上面的修改，我们再来看容器中的DNS报文，就只有下面几条了。
1 2 3 4 5 6 7 sudo nsenter -t 3885 -n tcpdump -i eth0 udp port 53 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 10:30:35.917282 IP 10.244.2.202.39480 > 10.96.0.10.domain: 60870+ A? google.com. (28) 10:30:35.919194 IP 10.244.2.202.39480 > 10.96.0.10.domain: 9908+ AAAA? google.com. (28) 10:30:35.927047 IP 10.96.0.10.domain > 10.244.2.202.39480: 60870 1/0/0 A 216.58.200.238 (54) 10:30:35.929089 IP 10.96.0.10.domain > 10.244.2.202.39480: 9908 1/0/0 AAAA 2404:6800:4008:801::200e (66)
这对于应用的性能会有一定的提升，具体可以参见Ref。
dns cache 我们观察一些python类型的容器应用，会发现它们会发出非常多的DNS请求，几乎每次涉及到域名都需要发出DNS请求；但是对于一些Java应用，会发现它们发出的DNS请求非常规律，一般是每30秒一个。
这是因为，不同语言对于dns cache的处理不同了。
目前来看，只有Java做了dns cache。从JDK 1.6开始，Java默认会对DNS做缓存，主要是以下两个配置：
networkaddress.cache.ttl：域名解析成功后，DNS缓存时间，默认是30秒
networkaddress.cache.negative.ttl：域名解析失败后，冷却时间，默认是10秒
其他语言可以支持，但都需要一定hack。
总结 本文从一个多余的DNS查询现象开始，介绍了FQDN和DNS的搜索域，回答了kubernetes为什么需要搜索域这个问题，并且提出了一个解决多余DNS查询的方案，以及介绍了不同语言对于dns cache的处理情况。
Ref：
