以下是重现的步骤:
minikube start
kubectl run nginx --image=nginx
kubectl expose deployment nginx --port=80 --type=ClusterIP
kubectl run -i --tty --rm alpine --image=alpine --restart=Never -- sh
apk add --no-cache bind-tools
现在让我们尝试查询kibe-dns以获取nginx
服务
nslookup
:
/ # nslookup nginx.default 10.96.0.10
Server: 10.96.0.10
Address: 10.96.0.10#53
Name: nginx.default.svc.cluster.local
Address: 10.97.239.175
和dig
:
dig nginx.default @10.96.0.10 any
; <<>> DiG 9.11.3 <<>> nginx.default @10.96.0.10 any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46414
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nginx.default. IN ANY
;; Query time: 279 msec
;; SERVER: 10.96.0.10#53(10.96.0.10)
;; WHEN: Sun Jun 03 15:31:15 UTC 2018
;; MSG SIZE rcvd: 42
如果我用nginx.default
替换名称nginx
,则无法更改。
minikube版本:v0.27.0, k8s版本:1.10.0
答案 0 :(得分:2)
很少有事情需要指出:
dig nginx.default.svc.cluster.local NS
您将看到没有托管名称服务器。只有在至少存在一个时才能指定一个。dig any
并没有真正起作用,所以在这种情况下,我担心你必须明确使用A
或将其留空(A是默认值) 结论:
改为运行dig nginx.default.svc.cluster.local
或dig nginx.default.svc.cluster.local A
。
答案 1 :(得分:1)
默认情况下,Dig 不会使用搜索路径完成查询。搜索路径在 /etc/resolv.conf
中设置。 +search
标志启用搜索路径完成。
+[no]搜索
使用 [不使用] 由 resolv.conf 中的 searchlist 或 domain 指令定义的搜索列表(如果有)。默认情况下不使用搜索列表。
https://linux.die.net/man/1/dig
我为 katacoda 创建了一个场景,它以交互方式通过相同的示例https://www.katacoda.com/bluebrown/scenarios/kubernetes-dns
首先创建并公开一个 pod,然后以交互方式启动另一个安装了 dnsutils 的 pod,从中可以进行 DNS 查询。
kubectl create namespace dev
kubectl run my-app --image nginx --namespace dev --port 80
kubectl expose pod my-app --namespace dev
kubectl run dnsutils --namespace dev --image tutum/dnsutils -ti -- bash
Nslookup 解析服务正常
$ nslookup my-app
...
Name: my-app.dev.svc.cluster.local
Address: 10.43.52.98
但是 dig 没有得到答案,为什么?
$ dig my-app
...
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...
为了理解为什么 dig 找不到服务,让我们看看/etc/resolv.conf
$ cat /etc/resolv.conf
search dev.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.43.0.10
options ndots:5
此文件包含具有以下格式的行。
search <namespace>.svc.cluster.local svc.cluster.local cluster.local
这意味着,当提供完全限定域名 (FQDN) 的不完整部分时,该文件可用于完成查询。但是,默认情况下 dig 不会这样做。我们可以使用 +search
标志来启用它。
dig +search my-app
...
;; QUESTION SECTION:
;my-app.dev.svc.cluster.local. IN A
;; ANSWER SECTION:
my-app.dev.svc.cluster.local. 5 IN A 10.43.52.98
现在服务名称已正确解析。您还可以通过将此命令的问题部分与前一个没有 +search
标志的部分进行比较,来了解查询是如何使用搜索路径完成的。
使用 FQDN 时,我们可以在没有 +search
标志的情况下获得相同的服务。 +short
标志不是必需的,但它会将输出减少到仅 IP 地址。
$ dig +short my-app.dev.svc.cluster.local
10.43.52.98
但是,使用 search
方法的好处是查询将自动解析为同一命名空间内的资源。这对于将相同配置应用于不同环境(例如生产和开发)非常有用。
不同命名空间中的资源总是需要通过 FQDN 来查找。
与 resolv.conf
中的搜索条目使用默认名称空间完成查询的方式相同,它将从左到右完成 FQDN 的任何部分。所以在下面的例子中,它将解析为本地集群。
$ dig +short +search my-app.dev
10.43.52.98