4

以下是重现的步骤：

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

如果我将 name 替换为nginx.defaultjust ，则没有任何变化nginx。

minikube 版本：v0.27.0，k8s 版本：1.10.0

4

2 回答 2

4

有几点需要指出：

  1. 始终使用“nginx.default.svc.cluster.local”，不要依赖工具为你完成。
  2. 运行dig nginx.default.svc.cluster.local NS你会看到它没有托管名称服务器。当至少存在一个时，您只能指定一个。
  3. 有趣的是，我发现dig any在 alpine 中并没有真正起作用，所以在这种情况下，恐怕您必须明确使用A或将其留空（A 是默认值）

结论：

运行dig nginx.default.svc.cluster.local或dig nginx.default.svc.cluster.local A代替。

于 2018-06-03T17:19:57.427 回答
3

回答

Dig 默认不使用搜索路径完成查询。搜索路径设置在/etc/resolv.conf. 该+search标志启用搜索路径完成。

从手册页

+[no]search
使用 [不使用] 由 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 解析服务ok

$ 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您还可以通过将此命令的问题部分与上一个不带标志的问题部分进行比较来查看查询是如何通过搜索路径完成的。

+search使用 FQDN 时，我们可以在没有标志的情况下获得相同的服务。该+short标志不是必需的，但它会将输出减少到仅 IP 地址。

$ dig +short my-app.dev.svc.cluster.local
10.43.52.98

但是，使用该search方法的好处是查询将自动解析到同一命名空间内的资源。这对于将相同的配置应用于不同的环境（例如生产和开发）很有用。

与中的搜索条目resolv.conf使用默认名称空间完成查询的方式相同，它将从左到右完成 FQDN 的任何部分。所以在下面的例子中，它将解析到本地集群。

$ dig +short +search my-app.dev
10.43.52.98
于 2021-06-25T12:03:20.457 回答