在kubernetes中定位DNS问题

在kubernetes中定位DNS问题

今天我们来说一说怎样定位kubernetes集群中DNS服务器无法解析的故障定位问题。

创建实验环境

首先，使用如下的内容编辑yaml文件dnsutils.yaml

apiVersion: v1kind: Podmetadata: name: dnsutils namespace: defaultspec: containers: - name: dnsutils image: gcr.io/kubernetes-e2e-test-images/dnsutils:1.3 command: - sleep - "3600" imagePullPolicy: IfNotPresent restartPolicy: Always

创建pod并且查看状态

$ kubectl apply -f https://k8s.io/examples/admin/dns/dnsutils.yamlpod/dnsutils createdkubectl get pods dnsutilsNAME READY STATUS RESTARTS AGEdnsutils 1/1 Running 0

当Pod在running状态的时候，我们就可以在环境中执行nslookup命令了。如果有下面的输出，那么，DNS就是正常运行的。

$ kubectl exec -ti dnsutils -- nslookup kubernetes.defaultServer: 10.0.0.10Address 1: 10.0.0.10Name: kubernetes.defaultAddress 1: 10.0.0.1

Debug的过程

一旦出现DNS无法解析的问题，我们就一般会按照下面的过程去debug问题

检查本地DNS配置

检查resolve.conf文件

kubectl exec -ti dnsutils -- cat /etc/resolv.conf

观察search的路径和name server的配置，应该是像下面这样（根据公有云环境不同，结果也有可能不同）

search default.svc.cluster.local svc.cluster.local cluster.local google.internal c.gce_project_id.internalnameserver 10.0.0.10options ndots:5

如果是想下面这样的问题就可能是coredns/kube-dns插件或者辅助他的Service的问题

kubectl exec -ti dnsutils -- nslookup kubernetes.defaultServer: 10.0.0.10Address 1: 10.0.0.10nslookup: can't resolve 'kubernetes.default'

或者是这样的问题

kubectl exec -ti dnsutils -- nslookup kubernetes.defaultServer: 10.0.0.10Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.localnslookup: can't resolve 'kubernetes.default'

检查DNS pod是否正常运行

我们可以使用kubectl get pods命令

CoreDNSkubectl get pods --namespace=kube-system -l k8s-app=kube-dnsNAME READY STATUS RESTARTS AGE...coredns-7b96bf9f76-5hsxb 1/1 Running 0 1hcoredns-7b96bf9f76-mvmmt 1/1 Running 0 1h...kube-dnskubectl get pods --namespace=kube-system -l k8s-app=kube-dnsNAME READY STATUS RESTARTS AGE...coredns-7b96bf9f76-5hsxb 1/1 Running 0 1hcoredns-7b96bf9f76-mvmmt 1/1 Running 0 1h...如果我们发现没有这个pod或者是pod处在failed/complated状态，那么dns插件就没有正确部署在环境当中，我们需要手动部署

检查DNS pod的错误日志

使用kubectl logs命令开查看DNS容器的日志

CoreDNSfor p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); do kubectl logs --namespace=kube-system $p; done下面是一个正常的CoreDNS的日志.:532018/08/15 14:37:17 [INFO] CoreDNS-1.2.22018/08/15 14:37:17 [INFO] linux/amd64, go1.10.3, 2e322f6CoreDNS-1.2.2linux/amd64, go1.10.3, 2e322f62018/08/15 14:37:17 [INFO] plugin/reload: Running configuration MD5 = 24e6c59e83ce706f07bcc82c31b1ea1ckube-dnskubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c kubednskubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c dnsmasqkubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name | head -1) -c sidecar如果我们发现有错误日志，就是以W,E或者F开头的行就是Warning,Error或者Failure。我们根据情况去kubernetes issues里面搜索。

DNS的service是不是启动

查看DNS的service资源是不是启动，使用kubectl get service命令

kubectl get svc --namespace=kube-systemNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE...kube-dns ClusterIP 10.0.0.10 53/UDP,53/TCP 1h...

注意，kube-dns和CoreDNS的service名字都叫做kube-dns。如果我们必须创建service或者他默认需要创建但是并没有创建成功，我们就需要debug service，那我们下个话题在说Service的debug.

DNS的endpoints是否被暴露

我们可以通过kubectl get endpoint命令来查看DNS的endpoint是否被暴露

kubectl get svc --namespace=kube-systemNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE...kube-dns ClusterIP 10.0.0.10 53/UDP,53/TCP 1h...

这个同样需要debug service

DNS的查询是否正常接收和处理

我们可以给CoreDNS添加log插件来确认CoreDNS是否正常接收请求了。CoreDNS的插件需要修改Corefile，而Corefile是一个叫做coredns的ConfigMap。我们需要使用edit命令

kubectl -n kube-system edit configmap coredns

在Corefile中添加log

apiVersion: v1kind: ConfigMapmetadata: name: coredns namespace: kube-systemdata: Corefile: | .:53 { log errors health kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure upstream fallthrough in-addr.arpa ip6.arpa } prometheus :9153 proxy . /etc/resolv.conf cache 30 loop reload loadbalance }

保存之后，可能需要1到两分钟，kubernetes才会把修改内容同步到CoreDNS pod当中，下面我们在做一些查询，然后观看日志，如果CoreDNS能够正常接收查询，我们应该可以看到下面的输出

.:532018/08/15 14:37:15 [INFO] CoreDNS-1.2.02018/08/15 14:37:15 [INFO] linux/amd64, go1.10.3, 2e322f6CoreDNS-1.2.0linux/amd64, go1.10.3, 2e322f62018/09/07 15:29:04 [INFO] plugin/reload: Running configuration MD5 = 162475cdf272d8aa601e6fe67a6ad42f2018/09/07 15:29:04 [INFO] Reloading complete172.17.0.18:41675 - [07/Sep/2018:15:29:11 +0000] 59925 "A IN kubernetes.default.svc.cluster.local. udp 54 false 512" NOERROR qr,aa,rd,ra 106 0.000066649s

最近的碰到的问题

一些Linux发行版(例如.Ubuntu）默认情况下使用本地DNS解析程序（systemd resolved）。systemd-resolved移动和替换/etc/resolv.conf文件，使得在解析服务器的dns地址时，可能导致循环转发。通过使用kubelet的--resolv conf选项指向正确的resolv.conf文件（在systemd解析的情况下，这是/run/systemd/resolve/resolv.conf文件). Kubernetes（>=1.11条)会自动检测已解析的systemd，并相应地调整kubelet标志。一些云上的定制主机，比如AWS的Linux，默认会使用VPC中的DNS server，而且这个通过修改/etc/resolv.conf文件也没办法指定DNS服务器，我们需要通过查询AWS的官方网站找到解决办法