DNS解析异常问题排查

索引

诊断流程

基本概念

• 集群内部域名：CoreDNS会将集群中的服务暴露为集群内部域名，默认以.cluster.local结尾，这类域名的解析通过CoreDNS内部缓存完成，不会从上游DNS服务器查询。

• 集群外部域名：在第三方DNS服务商、阿里云DNS云解析、PrivateZone等产品注册的权威解析，这类域名由CoreDNS的上游DNS服务器负责解析，CoreDNS仅做解析请求转发。

• 业务Pod：您部署在Kubernetes集群中的容器Pod，不包含Kubernetes自身系统组件的容器。

• 接入CoreDNS的业务Pod：容器内DNS服务器指向了CoreDNS的业务Pod。

• 接入NodeLocal DNSCache的业务Pod：集群中安装了NodeLocal DNSCache插件后，通过自动或手动方式注入DNSConfig的业务Pod。这类Pod在解析域名时，会优先访问本地缓存组件。如果访问本地缓存组件不通时，会访问CoreDNS提供的kube-dns服务。

异常诊断流程

1. 判断当前的异常原因。具体信息，请参见常见客户端报错。

   • 如果异常原因是域名不存在，请参见排查思路的《按解析异常的域名类型》。

   • 如果异常原因是无法连接至域名服务器，请参见排查思路的《按解析异常出现频次》。

2. 如果以上排查无果，请按以下步骤排查。

   • 检查业务Pod的DNS配置，是否已经接入CoreDNS。具体操作，请参见检查业务Pod的DNS配置。

     • 如果没有接入CoreDNS，则考虑是客户端负载原因或Conntrack表满导致解析失败。具体操作，请参见客户端负载原因导致解析失败和Conntrack表满。

     • 如果接入了CoreDNS，则按以下步骤排查。

       1. 通过检查CoreDNS Pod运行状态进行诊断。具体操作，请参见检查CoreDNS Pod运行状态和CoreDNS Pod运行状态异常。

       2. 通过检查CoreDNS运行日志进行诊断。具体操作，请参见检查CoreDNS运行日志和集群外部域名解析异常。

       3. 确认异常是否能够稳定复现。

          1. 如果异常稳定复现，请参见检查CoreDNS DNS查询请求日志和检查业务Pod到CoreDNS的网络连通性。

          2. 如果异常不能稳定复现，请参见抓包。

   • 如果使用了NodeLocal DNSCache，请参见NodeLocal DNSCache未生效和PrivateZone域名解析异常。

3. 如果以上排查无果，请提交工单排查。

常见客户端报错

排查思路

常见检查方法

检查业务Pod的DNS配置

• 命令

  #查看foo容器的YAML配置，并确认DNSPolicy字段是否符合预期。
  kubectl get pod foo -o yaml
  
  #当DNSPolicy符合预期时，可以进一步进入Pod容器中，查看实际生效的DNS配置。
  
  #通过bash命令进入foo容器，若bash不存在可使用sh代替。
  kubectl exec -it foo bash
  
  #进入容器后，可以查看DNS配置，nameserver后面为DNS服务器地址。
  cat /etc/resolv.conf

• DNS Policy配置说明

  DNS Policy示例如下所示。

  apiVersion: v1
  kind: Pod
  metadata:
    name: <pod-name>
    namespace: <pod-namespace>
  spec:
    containers:
    - image: <container-image>
      name: <container-name>
  
  #默认场景下的DNS Policy。
    dnsPolicy: ClusterFirst
  #使用了NodeLocal DNSCache时的DNS Policy。
    dnsPolicy: None
    dnsConfig:
      nameservers:
      - 169.254.20.10
      - 172.21.0.10
      options:
      - name: ndots
        value: "3"
      - name: timeout
        value: "1"
      - name: attempts
        value: "2"
      searches:
      - default.svc.cluster.local
      - svc.cluster.local
      - cluster.local
  
    securityContext: {}
    serviceAccount: default
    serviceAccountName: default
    terminationGracePeriodSeconds: 30

  DNSPolicy字段值	使用的DNS服务器
  Default	只适用于不需要访问集群内部服务的场景。Pod创建时会从ECS节点/etc/resolv.conf文件继承DNS服务器列表。
  ClusterFirst	此为DNSPolicy默认值，Pod会将CoreDNS提供的kube-dns服务IP作为DNS服务器。开启HostNetwork的Pod，如果选择ClusterFirst模式，效果等同于Default模式。
  ClusterFirstWithHostNet	开启HostNetwork的Pod，如果选择ClusterFirstWithHostNet模式，效果等同于ClusterFirst。
  None	配合DNSConfig字段，可用于自定义DNS服务器和参数。在NodeLocal DNSCache开启注入时，DNSConfig会将DNS服务器指向本地缓存IP及CoreDNS提供的kube-dns服务IP。

检查CoreDNS Pod运行状态

检查CoreDNS运行日志

命令

kubectl -n kube-system logs -f --tail=500 --timestamps coredns-xxxxxxxxx-xxxxx

检查CoreDNS DNS查询请求日志

命令

DNS查询请求日志仅会在开启CoreDNS的Log插件后，才会打印到容器日志中。关于开启Log插件的具体操作，请参见CoreDNS配置说明。

命令与检查CoreDNS运行日志相同，请参见检查CoreDNS运行日志。

检查CoreDNS Pod的网络连通性

操作步骤

1. 登录CoreDNS Pod所在集群节点。

2. 执行ps aux | grep coredns，查询CoreDNS的进程ID。

3. 执行nsenter -t <pid> -n bash，进入CoreDNS所在容器网络命名空间，其中pid为上一步得到的进程ID。

4. 测试网络连通性。

   1. 运行telnet <apiserver_clusterip> 6443，测试Kubernetes API Server的连通性。

      其中apiserver_clusterip为default命名空间下Kubernetes服务的IP地址。

   2. 运行dig <domain> @<upstream_dns_server_ip>，测试CoreDNS Pod到上游DNS服务器的连通性。

      其中domain为测试域名，upstream_dns_server_ip为上游DNS服务器地址，默认为100.100.2.136和100.100.2.138。

常见问题

检查业务Pod到CoreDNS的网络连通性

操作步骤

1. 选择以下任意一种方式，进入客户端Pod容器网络。

   • 方法一：使用kubectl exec命令。

   • 方法二：

     1. 登录业务Pod所在集群节点。

     2. 执行ps aux | grep <业务进程名>命令，查询业务容器的进程ID。

     3. 执行nsenter -t <pid> -n bash命令，进入业务Pod所在容器网络命名空间。

        其中pid为上一步得到的进程ID。

   • 方法三：如果频繁重启，请按以下步骤操作。

     1. 登录业务Pod所在集群节点。

     2. 执行docker ps -a | grep <业务容器名>命令，查询k8s_POD_ 开头的沙箱容器，记录容器ID。

     3. 执行docker inspect <沙箱容器 ID> | grep netns命令，查询/var/run/docker/netns/xxxx的容器网络命名空间路径。

     4. 执行nsenter -n<netns 路径> bash命令，进入容器网络命名空间。

        其中netns 路径为上一步得到的路径。

        说明

        -n和<netns 路径>之间不加空格。

2. 测试网络连通性。

   1. 执行dig <domain> @<kube_dns_svc_ip>命令，测试业务Pod到CoreDNS服务kube-dns解析查询的连通性。

      其中<domain>为测试域名，<kube_dns_svc_ip>为kube-system命名空间中kube-dns的服务IP。

   2. 执行ping <coredns_pod_ip>命令，测试业务Pod到CoreDNS容器副本的连通性。

      其中<coredns_pod_ip>为kube-system命名空间中CoreDNS Pod的IP。

   3. 执行dig <domain> @<coredns_pod_ip>命令，测试业务Pod到CoreDNS容器副本解析查询的连通性。

      其中<domain>为测试域名，<coredns_pod_ip>为kube-system命名空间中CoreDNS Pod的IP。

常见问题

抓包

当无法定位问题时，需要抓包进行辅助诊断。

1. 登录出现异常的业务Pod、CoreDNS Pod所在节点。

2. 在ECS（非容器内）执行以下命令，可以将最近所有的53端口信息抓取到文件中。

   tcpdump -i any port 53 -C 20 -W 200 -w /tmp/client_dns.pcap

3. 结合业务日志的报错定位到精准的报错时间的报文信息。

   说明

   • 在正常情况下，抓包对业务无影响，仅会增加小部分的CPU负载和磁盘写入。

   • 以上命令会对抓取到的包进行rotate，最多可以写200个20 MB的.pcap文件。

集群外部域名解析异常

问题现象

业务Pod可以正常解析集群内部域名，但无法解析某些集群外部域名。

问题原因

上游服务器域名解析返回异常。

解决方案

检查CoreDNS DNS查询请求日志。

常见请求日志

# 其中包含状态码RCODE NOERROR，代表解析结果正常返回。
[INFO] 172.20.2.25:44525 - 36259 "A IN redis-master.default.svc.cluster.local. udp 56 false 512" NOERROR qr,aa,rd 110 0.000116946s

常见返回码RCODE

当CoreDNS DNS查询请求日志中显示集群外部域名返回为NXDOMAIN、SERVFAIL、REFUSED时，说明CoreDNS的上游DNS服务器返回异常。

默认情况下，集群中CoreDNS的上游DNS服务器是VPC提供的DNS服务器（100.100.2.136 和 100.100.2.138）。您可以提交工单至云服务器ECS产品。提交工单时请注明以下信息。

新增Headless类型域名无法解析

问题现象

接入CoreDNS的业务Pod无法解析新增的Headless类型域名。

问题原因

1.7.0以前版本CoreDNS会在API Server抖动时异常退出，导致Headless域名停止更新。

解决方案

升级CoreDNS至1.7.0以上。具体操作，请参见【组件升级】CoreDNS升级公告。

升级CoreDNS后Headless类型域名无法解析

问题现象

部分较低版本开源组件（低版本etcd、nacos、kafka等）在K8s 1.20及以上版本和 CoreDNS 1.8.4及以上版本的环境中无法正常工作。

问题原因

1.8.4及以上版本的CoreDNS优先使用EndpointSlice API同步K8s内服务IP信息。一些开源组件在初始化阶段会使用Endpoint API 提供的注解service.alpha.kubernetes.io/tolerate-unready-endpoints来发布尚未就绪的服务。该注解在EndpointSlice API中已经废弃，并被publishNotReadyAddresses所替代。因此CoreDNS升级后，无法发布未就绪的服务，导致这些组件无法进行服务发现。

解决方案

检查开源组件的YAML或Helm Chart中是否包含service.alpha.kubernetes.io/tolerate-unready-endpoints注解，如果包含则可能无法正常工作，您需要升级开源组件或咨询开源组件社区。

StatefulSets Pod域名无法解析

问题现象

Headless服务无法通过Pod域名解析。

问题原因

StatefulSets Pod YAML中ServiceName必须和其暴露SVC的名字一致，否则无法访问Pod域名（例如pod.headless-svc.ns.svc.cluster.local），只能访问到服务域名（例如headless-svc.ns.svc.cluster.local）。

解决方案

修改StatefulSets Pod YAML中ServiceName名称。

安全组、交换机ACL配置错误

问题现象

部分节点或全部节点上接入CoreDNS的业务，Pod解析域名持续性失败。

问题原因

修改了ECS或容器使用的安全组（或交换机ACL），拦截了UDP协议下53端口的通信。

解决方案

恢复安全组、交换机ACL的配置，放开其以UDP协议对53端口的通信。

容器网络连通性异常

问题现象

部分节点或全部节点上接入CoreDNS的业务，Pod解析域名持续性失败。

问题原因

由于容器网络或其它原因导致的UDP协议53端口持续性不通。

解决方案

请提交工单排查。

CoreDNS Pod负载高

问题现象

• 部分节点或全部节点接入CoreDNS的业务，Pod解析域名的延迟增加、概率性或持续性失败。

• 检查CoreDNS Pod运行状态发现各副本CPU、Memory使用量接近其资源限制。

问题原因

由于CoreDNS副本数不足、业务请求量高等情况导致的CoreDNS负载高。

解决方案

• 考虑采用NodeLocal DNSCache缓存方案，提升DNS解析性能，降低CoreDNS负载。具体操作，请参见使用NodeLocal DNSCache。

• 适当扩充CoreDNS副本数，使每个Pod的峰值CPU始终低于节点空闲CPU数。

CoreDNS Pod负载不均

问题现象

• 部分接入CoreDNS的业务Pod解析域名的延迟增加、概率性或持续性失败。

• 检查CoreDNS Pod运行状态发现各副本CPU使用量负载不均衡。

• CoreDNS副本数少于两个，或多个CoreDNS副本位于同节点上。

问题原因

由于CoreDNS副本调度不均、Service亲和性设置导致CoreDNS Pod负载不均衡。

解决方案

• 扩容并打散CoreDNS副本到不同的节点上。

• 负载不均衡时，可禁用kube-dns服务的亲和性属性。具体操作，请参见配置Kube-DNS服务。

CoreDNS Pod运行状态异常

问题现象

• 部分接入CoreDNS的业务Pod解析域名的延迟增加、概率性或持续性失败。

• CoreDNS副本状态Status不处于Running状态，或重启次数RESTARTS持续增加。

• CoreDNS运行日志中出现异常。

问题原因

由于CoreDNS YAML模板、配置文件等导致CoreDNS运行异常。

解决方案

检查CoreDNS Pod运行状态和运行日志。

常见异常日志及处理方案

客户端负载原因导致解析失败

问题现象

业务高峰期间或突然偶发的解析失败，ECS监控显示机器网卡重传率、CPU负载有异常。

问题原因

接入CoreDNS的业务Pod所在ECS负载达到100%等情况导致UDP报文丢失。

解决方案

• 建议提交工单排查原因。

• 考虑采用NodeLocal DNSCache缓存方案，提升DNS解析性能，降低CoreDNS负载。具体操作，请参见使用NodeLocal DNSCache。

Conntrack表满

问题现象

• 部分节点或全部节点上接入CoreDNS的业务，Pod解析域名在业务高峰时间段内出现大批量域名解析失败，高峰结束后失败消失。

• 运行dmesg -H，滚动到问题对应时段的日志，发现出现conntrack full字样的报错信息。

问题原因

Linux内Conntrack表条目有限，无法进行新的UDP或TCP请求。

解决方案

增加Conntrack表限制。具体操作，请参见如何提升Linux连接跟踪Conntrack数量限制？。

AutoPath插件异常

问题现象

• 解析集群外部域名时，概率性解析失败或解析到错误的IP地址，解析集群内部域名无异常。

• 高频创建容器时，集群内部服务域名解析到错误的IP地址。

问题原因

CoreDNS处理缺陷导致AutoPath无法正常工作。

解决方案

A记录和AAAA记录并发解析异常

问题现象

• 接入CoreDNS的业务Pod解析域名概率性失败。

• 从抓包或检查CoreDNS DNS查询请求日志可以发现，A和AAAA通常在同一时间的出现，并且请求的源端口一致。

问题原因

• 并发A和AAAA的DNS请求触发Linux内核Conntrack模块缺陷，导致UDP报文丢失。

• 低版本的libc(<2.33)在ARM机型上在同时发起A和AAAA请求时的并发问题，导致请求超时重传，请参见GLIBC#26600。

解决方案

• 考虑采用NodeLocal DNSCache缓存方案，提升DNS解析性能，降低CoreDNS负载。具体操作，请参见使用NodeLocal DNSCache。

• CentOS、Ubuntu等使用libc的基础镜像，升级libc版本到2.33或以上版本避免A和AAAA并发解析问题。

• CentOS、Ubuntu等基础镜像，可以通过options timeout:2 attempts:3 rotate single-request-reopen等参数优化。

• 如果容器镜像是以Alpine制作的，建议更换基础镜像。更多信息，请参见Alpine。

• PHP类应用短连接解析问题较多，如果使用的是PHP Curl的调用，可以使用CURL_IPRESOLVE_V4参数仅发送IPv4解析。更多信息，请参见函数说明。

IPVS缺陷导致解析异常

问题现象

当集群节点扩缩容、节点关机、CoreDNS缩容时，出现概率性解析失败，通常时长在五分钟左右。

问题原因

若您集群的kube-proxy负载均衡模式为IPVS，在CentOS、Alibaba Cloud Linux 2内核版本小于4.19.91-25.1.al7.x86_64的节点上，摘除IPVS UDP类型后端后，一段时间内若新发起的UDP报文源端口冲突，该报文会被丢弃。

解决方案

• 考虑采用NodeLocal DNSCache缓存方案，可以容忍IPVS丢包。具体操作，请参见使用NodeLocal DNSCache。

• 优化IPVS UDP超时时间。具体操作，请参见配置IPVS类型集群的UDP超时时间。

NodeLocal DNSCache未生效

问题现象

NodeLocal DNSCache没有流量进入，所有请求仍在CoreDNS上。

问题原因

• 未配置DNSConfig注入，业务Pod实际仍配置了CoreDNS kube-dns服务IP作为DNS服务器地址。

• 业务Pod采用Alpine作为基础镜像，Alpine基础镜像会并发请求所有nameserver，包括本地缓存和CoreDNS。

解决方案

• 配置DNSConfig自动注入。具体操作，请参见使用NodeLocal DNSCache。

• 如果容器镜像是以Alpine制作的，建议更换基础镜像。更多信息，请参见Alpine。

PrivateZone域名解析异常

问题现象

对于接入NodeLocal DNSCache的业务，Pod无法解析PrivateZone上注册的域名，或无法解析包含vpc-proxy字样的阿里云云产品API域名，或解析结果不正确。

问题原因

PrivateZone不支持TCP协议，需要使用UDP协议访问。

解决方案

在CoreDNS中配置prefer_udp。具体操作，请参见CoreDNS配置说明。