From 53f7f6e3885787527bd8a2d6a017c209e87426fe Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sat, 15 Aug 2020 14:13:15 +0800 Subject: [PATCH] [zh] Resync DNS debugging solution task --- .../dns-debugging-resolution.md | 460 +++++++----------- 1 file changed, 173 insertions(+), 287 deletions(-) diff --git a/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md b/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md index 5a34f2331d..423c8e5d8f 100644 --- a/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md +++ b/content/zh/docs/tasks/administer-cluster/dns-debugging-resolution.md @@ -1,34 +1,37 @@ --- title: 调试 DNS 问题 content_type: task +min-kubernetes-server-version: v1.6 --- - 这篇文章提供了一些关于 DNS 问题诊断的方法。 ## {{% heading "prerequisites" %}} - +{{< include "task-tutorial-prereqs.md" >}} + + + +你的集群必须使用了 CoreDNS {{< glossary_tooltip text="插件" term_id="addons" >}} +或者其前身，`kube-dns`。 + +{{< version-check >}} -- {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -- Kubernetes 1.6 或者以上版本。 -- 集群必须使用了 `coredns` (或者 `kube-dns`)插件。 - - ### 创建一个简单的 Pod 作为测试环境 -新建一个名为 busybox.yaml 的文件并填入下列内容： +{{< codenew file="admin/dns/dnsutils.yaml" >}} -{{< codenew file="admin/dns/busybox.yaml" >}} - -然后使用这个文件创建一个 Pod 并验证其状态： +使用上面的清单来创建一个 Pod： ```shell -kubectl create -f https://k8s.io/examples/admin/dns/busybox.yaml -pod/busybox created +kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yaml +``` -kubectl get pods busybox -NAME READY STATUS RESTARTS AGE -busybox 1/1 Running 0 +``` +pod/dnsutils created ``` +验证其状态： +```shell +kubectl get pods dnsutils +``` + +``` +NAME READY STATUS RESTARTS AGE +dnsutils 1/1 Running 0 +``` + + - -只要 Pod 处于 running 状态，您就可以在环境里执行 `nslookup` 。 -如果您看到类似下列的内容，则表示 DNS 是正常运行的。 +一旦 Pod 处于运行状态，你就可以在该环境里执行 `nslookup`。 +如果你看到类似下列的内容，则表示 DNS 是正常运行的。 ```shell -kubectl exec -ti busybox -- nslookup kubernetes.default +kubectl exec -i -t dnsutils -- nslookup kubernetes.default +``` +``` Server: 10.0.0.10 Address 1: 10.0.0.10 @@ -87,42 +88,34 @@ Name: kubernetes.default Address 1: 10.0.0.1 ``` + 如果 `nslookup` 命令执行失败，请检查下列内容： - ### 先检查本地的 DNS 配置 查看 resolv.conf 文件的内容 -(阅读下面的 [从节点继承 DNS 配置](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) 和 -[已知问题](#known-issues) ，获取更多信息) +（阅读[从节点继承 DNS 配置](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/) 和 +后文的[已知问题](#known-issues) ，获取更多信息) ```shell -kubectl exec busybox cat /etc/resolv.conf +kubectl exec -ti dnsutils -- cat /etc/resolv.conf ``` -验证 search 和 name server 的配置是否类似下面的配置 -(注意 search 根据不同的云提供商可能会有所不同): + +验证 search 和 nameserver 的配置是否与下面的内容类似 +（注意 search 根据不同的云提供商可能会有所不同)： ``` search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internal @@ -131,34 +124,18 @@ options ndots:5 ``` - -下列错误表示 coredns/kube-dns 或者相关服务出现了问题： +下列错误表示 CoreDNS （或 kube-dns）插件或者相关服务出现了问题： + +``` +kubectl exec -i -t dnsutils -- nslookup kubernetes.default +``` + +输出为： ``` -kubectl exec -ti busybox -- nslookup kubernetes.default Server: 10.0.0.10 Address 1: 10.0.0.10 @@ -168,7 +145,6 @@ nslookup: can't resolve 'kubernetes.default' 或者 ``` -kubectl exec -ti busybox -- nslookup kubernetes.default Server: 10.0.0.10 Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local @@ -176,44 +152,19 @@ nslookup: can't resolve 'kubernetes.default' ``` - ### 检查 DNS Pod 是否运行 使用 `kubectl get pods` 命令来验证 DNS Pod 是否运行。 -对于 CoreDNS 的情况: - ```shell kubectl get pods --namespace=kube-system -l k8s-app=kube-dns +``` + +``` NAME READY STATUS RESTARTS AGE ... coredns-7b96bf9f76-5hsxb 1/1 Running 0 1h @@ -221,52 +172,37 @@ coredns-7b96bf9f76-mvmmt 1/1 Running 0 1h ... ``` -或者是 kube-dns: - -```shell -kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -NAME READY STATUS RESTARTS AGE -... -kube-dns-v19-ezo1y 3/3 Running 0 1h -... -``` - -如果您发现没有 pod 在运行，或者这些 Pod 的状态是 failed 或者 completed， 那可能这个 DNS 插件在您当前的环境里并没有成功部署，您将需要手动去部署它。 + +{{< note >}} +对于 CoreDNS 和 kube-dns 部署而言，标签 `k8s-app` 的值都应该是 `kube-dns`。 +{{< /note >}} +如果你发现没有 CoreDNS Pod 在运行，或者该 Pod 的状态是 failed 或者 completed， +那可能这个 DNS 插件在您当前的环境里并没有成功部署，你将需要手动去部署它。 + - -### 检查 DNS pod 里的错误 +### 检查 DNS Pod 里的错误 使用 `kubectl logs` 命令来查看 DNS 容器的日志信息。 -对于 CoreDNS: - ```shell -for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); do kubectl logs --namespace=kube-system $p; done +kubectl logs --namespace=kube-system -l k8s-app=kube-dns ``` + 下列是一个正常运行的 CoreDNS 日志信息： ``` @@ -279,146 +215,99 @@ linux/amd64, go1.10.3, 2e322f6 ``` +查看是否日志中有一些可疑的或者意外的消息。 -对于 kube-dns, 总共有三种类型的日志需要查看： - -```shell -kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c kubedns - -kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c dnsmasq - -kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c sidecar -``` - -看日志信息里是否有可疑的错误，对于 kube-dns, 一个 '`W`', '`E`' 或者 '`F`' 开头的行表示对应的 Warning（警告）， Error（错误）或者 Failure（失败）。请搜索日志等级是否有这样的关键字的日志信息并使用 [kubernetes issues](https://github.com/kubernetes/kubernetes/issues) 来提交错误报告。 + ### 检查是否启用了 DNS 服务 -使用`kubectl get service` 命令来检查 DNS 服务是否已经启用。 +使用 `kubectl get service` 命令来检查 DNS 服务是否已经启用。 ```shell kubectl get svc --namespace=kube-system +``` + +``` NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ... kube-dns ClusterIP 10.0.0.10 53/UDP,53/TCP 1h ... ``` -注意不管是 CoreDNS 还是 kube-dns ， 这个 service 的名字都会是“kube-dns” 。 -如果您已经创建了这个 service 或者说在这个例子里它应该是默认自动创建的，但是它并没有出现，请阅读 [services 纠错](/docs/tasks/debug-application-cluster/debug-service/)来获取更多信息。 + + +{{< note >}} +不管是 CoreDNS 还是 kube-dns，这个服务的名字都会是 `kube-dns` 。 +{{< /note >}} +如果你已经创建了 DNS 服务，或者该服务应该是默认自动创建的但是它并没有出现， +请阅读[调试服务](/zh/docs/tasks/debug-application-cluster/debug-service/) +来获取更多信息。 + +### DNS 的末端公开了吗？ + +你可以使用 `kubectl get endpoints` 命令来验证 DNS 的末端是否公开了。 ```shell kubectl get ep kube-dns --namespace=kube-system +``` +``` NAME ENDPOINTS AGE kube-dns 10.180.3.17:53,10.180.3.17:53 1h ``` + +如果你没看到对应的末端，请阅读 +[调试服务](/zh/docs/tasks/debug-application-cluster/debug-service/)的末端部分。 -### DNS 的 endpoints 公开了吗？ - -您可以使用 `kubectl get endpoints`命令来验证 DNS 的 endpoint 是否公开了。 - -```shell -kubectl get ep kube-dns --namespace=kube-system -NAME ENDPOINTS AGE -kube-dns 10.180.3.17:53,10.180.3.17:53 1h -``` - -如果您没看到对应的 endpoints， 请阅读[services 纠错](/docs/tasks/debug-application-cluster/debug-service/)的 endpoints 小节。 - -若需要更多的 Kubernetes DNS 例子，请在 Kubernetes GitHub 仓库里查看[cluster-dns 例子](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns) 。 +若需要了解更多的 Kubernetes DNS 例子，请在 Kubernetes GitHub 仓库里查看 +[cluster-dns 示例](https://github.com/kubernetes/examples/tree/master/staging/cluster-dns)。 - ### DNS 查询有被接收或者执行吗？ -您可以通过给 CoreDNS 的配置文件 (也叫 Corefile)添加`log`插件来判断查询是否被正确接收。 - CoreDNS 的 Corefile 被保存在一个叫 `coredns` 的 ConfigMap 里，使用下列命令来编辑它： +你可以通过给 CoreDNS 的配置文件（也叫 Corefile）添加 `log` 插件来检查查询是否被正确接收。 +CoreDNS 的 Corefile 被保存在一个叫 `coredns` 的 ConfigMap 里，使用下列命令来编辑它： ``` kubectl -n kube-system edit configmap coredns ``` - -然后类似下面的例子给 Corefile 添加 `log`。 +然后按下面的例子给 Corefile 添加 `log`。 ``` apiVersion: v1 @@ -438,38 +327,27 @@ data: fallthrough in-addr.arpa ip6.arpa } prometheus :9153 - proxy . /etc/resolv.conf + forward . /etc/resolv.conf cache 30 loop reload loadbalance } - ``` -保存这些更改后，您可能会需要等待一到两分钟让 Kubernetes 把这些更改应用到 CoreDNS 的 pods 里。 - +保存这些更改后，你可能会需要等待一到两分钟让 Kubernetes 把这些更改应用到 +CoreDNS 的 Pod 里。 + - -接下来，发起一些查询并依照本文上面章节的内容查看日志信息，如果 CoreDNS 的 pods 接收到这些查询，您将可以在日志信息里看到他们。 +接下来，发起一些查询并依照前文所述查看日志信息，如果 CoreDNS 的 Pod 接收到这些查询， +你将可以在日志信息里看到它们。 下面是日志信息里的查询例子： @@ -486,65 +364,73 @@ linux/amd64, go1.10.3, 2e322f6 ``` +## 已知问题 {#known-issues} -## 已知问题 - -有些 Linux 发行版本 (比如 Ubuntu)， 默认使用一个本地的 DNS 解析器 (systemd-resolved)。 -Systemd-resolved 会用一个 stub 文件来覆盖 `/etc/resolv.conf`从而在解析域名的时候导致了重复向 DNS 上游服务器推送请求。 这个问题可以通过手动指定 kubelet 的 `--resolv-conf` 标签为正确的 `resolv.conf` (如果是 `systemd-resolved`，则这个文件路径为 `/run/systemd/resolve/resolv.conf`) 来解决。 -kubeadm (>= 1.11) 会自动检测`systemd-resolved`并对应的更改 kubelet 的标签。 +有些 Linux 发行版本（比如 Ubuntu）默认使用一个本地的 DNS 解析器（systemd-resolved）。 +`systemd-resolved` 会用一个存根文件（Stub File）来覆盖 `/etc/resolv.conf` 内容， +从而可能在上游服务器中解析域名产生转发环（forwarding loop）。 这个问题可以通过手动指定 +kubelet 的 `--resolv-conf` 标志为正确的 `resolv.conf`（如果是 `systemd-resolved`， +则这个文件路径为 `/run/systemd/resolve/resolv.conf`）来解决。 +kubeadm 会自动检测 `systemd-resolved` 并对应的更改 kubelet 的命令行标志。 +Kubernetes 的安装并不会默认配置节点的 `resolv.conf` 文件来使用集群的 DNS 服务，因为这个配置对于不同的发行版本是不一样的。这个问题应该迟早会被解决的。 -Linux's libc is impossibly stuck ([see this bug from -2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)) with limits of just -3 DNS `nameserver` records and 6 DNS `search` records. Kubernetes needs to -consume 1 `nameserver` record and 3 `search` records. This means that if a -local installation already uses 3 `nameserver`s or uses more than 3 `search`es, -some of those settings will be lost. As a partial workaround, the node can run -`dnsmasq` which will provide more `nameserver` entries, but not more `search` -entries. You can also use kubelet's `--resolv-conf` flag. + +Linux 的 libc 限制 `nameserver` 只能有三个记录。不仅如此，对于 glibc-2.17-222 +之前的版本（[参见此 Issue 了解新版本的更新](https://access.redhat.com/solutions/58028)），`search` 的记录不能超过 6 个 +（ [详情请查阅这个 2005 年的 bug](https://bugzilla.redhat.com/show_bug.cgi?id=168253)）。 +Kubernetes 需要占用一个 `nameserver` 记录和三个`search`记录。 +这意味着如果一个本地的安装已经使用了三个 `nameserver` 或者使用了超过三个 +`search` 记录，而你的 glibc 版本也在有问题的版本列表中，那么有些配置很可能会丢失。 +为了绕过 DNS `nameserver` 个数限制，节点可以运行 `dnsmasq`，以提供更多的 +`nameserver` 记录。你也可以使用kubelet 的 `--resolv-conf` 标志来解决这个问题。 +要想修复 DNS `search` 记录个数限制问题，可以考虑升级你的 Linux 发行版本，或者 +升级 glibc 到一个不再受此困扰的版本。 + -Kubernetes 的安装并不会默认配置节点的 `resolv.conf` 文件来使用集群的 DNS 服务，因为这个配置对于不同的发行版本是不一样的。这个问题应该迟早会被解决的。 +如果你使用 Alpine 3.3 或更早版本作为你的基础镜像，DNS 可能会由于 Alpine 中 +一个已知的问题导致无法正常工作。 +请查看[这里](https://github.com/kubernetes/kubernetes/issues/30215)获取更多信息。 -Linux 的 libc 会在仅有三个 DNS 的 `nameserver` 和六个 DNS 的`search` 记录时会不可思议的卡死 ([详情请查阅这个2005年的bug](https://bugzilla.redhat.com/show_bug.cgi?id=168253))。Kubernetes 需要占用一个 `nameserver` 记录和三个`search`记录。这意味着如果一个本地的安装已经使用了三个`nameserver`或者使用了超过三个的 `search`记录，那有些配置很可能会丢失。有一个不完整的解决方案就是在节点上使用`dnsmasq`来提供更多的`nameserver`配置，但是无法提供更多的`search`记录。您也可以使用kubelet 的 `--resolv-conf` 标签来解决这个问题。 - -如果您是使用 Alpine 3.3 或者更早版本作为您的基础镜像，DNS 可能会由于Alpine 一个已知的问题导致无法正常工作，请查看[这里](https://github.com/kubernetes/kubernetes/issues/30215)获取更多资料。 +## {{% heading "whatsnext" %}} - -## 参考 - -- [Services 和 Pods 的 DNS 指南](/docs/concepts/services-networking/dns-pod-service/) -- [kube-dns DNS 插件文档](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/kube-dns/README.md) - -## 接下来 - -- [集群里自动伸缩 DNS Service](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/). - +- 参阅[自动扩缩集群中的 DNS 服务](/zh/docs/tasks/administer-cluster/dns-horizontal-autoscaling/). +- 阅读[服务和 Pod 的 DNS](/zh/docs/concepts/services-networking/dns-pod-service/)