问题描述
通过为我的 kubernetes 集群中的服务运行 dig 命令,coredns 只提供服务名称而不是 IP。有谁知道为什么会这样?
解决方法
这与dig实用程序和DNS的工作方式有关。
注意运行时:
dig <your-service-name>
您实际上是在询问您的 CoreDNS 这个特定的字符串,而简单的服务名称甚至不是有效的域名。看看下面的例子:
root@python-client:/# dig my-release-mysql
; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> my-release-mysql
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY,status: NXDOMAIN,id: 27445
;; flags: qr rd ra; QUERY: 1,ANSWER: 0,AUTHORITY: 1,ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0,flags:; udp: 512
;; QUESTION SECTION:
;my-release-mysql. IN A
;; AUTHORITY SECTION:
. 86399 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2021012500 1800 900 604800 86400
;; Query time: 19 msec
;; SERVER: 10.3.240.10#53(10.3.240.10)
;; WHEN: Mon Jan 25 16:22:12 UTC 2021
;; MSG SIZE rcvd: 120
如您所见,它甚至不包含 "ANSWER"
部分 (ANSWER: 0
),如果您仔细查看 "QUESTION"
部分:
;; QUESTION SECTION:
;my-release-mysql. IN A
您会注意到 dig 向 CoreDNS 请求 A
的 my-release-mysql.
记录,正如我已经提到的,这甚至不是一个有效的域名。
请注意,CoreDNS 不会保留 my-release-mysql.
的任何记录,因此当您询问此类“域”时,它对此一无所知。
如果您请求 A
记录以获得有效的完全限定域名 (FQDN),您将得到预期的响应:
root@python-client:/# dig my-release-mysql.default.svc.cluster.local
; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> my-release-mysql.default.svc.cluster.local
;; global options: +cmd
;; Got answer:
;; WARNING: .local is reserved for Multicast DNS
;; You are currently testing what happens when an mDNS query is leaked to DNS
;; ->>HEADER<<- opcode: QUERY,status: NOERROR,id: 47573
;; flags: qr aa rd ra; QUERY: 1,ANSWER: 1,AUTHORITY: 0,ADDITIONAL: 0
;; QUESTION SECTION:
;my-release-mysql.default.svc.cluster.local. IN A
;; ANSWER SECTION:
my-release-mysql.default.svc.cluster.local. 30 IN A 10.3.244.87
;; Query time: 0 msec
;; SERVER: 10.3.240.10#53(10.3.240.10)
;; WHEN: Mon Jan 25 15:59:55 UTC 2021
;; MSG SIZE rcvd: 76
再次仔细查看 "QUESTION"
和 "ANSWER"
部分:
;; QUESTION SECTION:
;my-release-mysql.default.svc.cluster.local. IN A
;; ANSWER SECTION:
my-release-mysql.default.svc.cluster.local. 30 IN A 10.3.244.87
如您所见,当我们向 QUESTION SECTION
中的 CoreDNS 询问 A
的 my-release-mysql.default.svc.cluster.local.
记录时,该记录恰好是一个有效的 FQDN(与此 DNS 服务器为其保存记录的 my-release-mysql.
不同),我们在 ANSWER SECTION
中得到正确响应。
请注意,dig 实用程序不会使用您的 /etc/resolv.conf
中的条目,这些条目可能如下所示:
root@python-client:/# cat /etc/resolv.conf
nameserver 10.3.240.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
相反,它向 DNS 服务器查询原始字符串 my-release-mysql.
。
host
或 nslookup
等工具与 dig 不同,在进行 DNS 查找时利用 /etc/resolv.conf
的内容。因此,不是向 CoreDNS 询问原始 my-release-mysql
,而是添加 default.svc.cluster.local
后缀并将此类查询发送到 CoreDNS,例如:
root@python-client:/# host my-release-mysql
my-release-mysql.default.svc.cluster.local has address 10.3.244.87
请注意,尽管我们将 my-release-mysql
作为 host
命令的参数,但它与 search
文件的 /etc/resolv.conf
部分中的第一个条目匹配,这恰好是 default.svc.cluster.local
并且查询 DNS 服务器不是关于 my-release-mysql
,而是关于它保留记录的完全合格的域名 my-release-mysql.default.svc.cluster.local
。
与 nslookup
工具相同:
root@python-client:/# nslookup my-release-mysql
Server: 10.3.240.10
Address: 10.3.240.10#53
Name: my-release-mysql.default.svc.cluster.local
Address: 10.3.244.87