本文介绍了关于Kubernetes集群内域名解析异常的常见问题及解决方案。

集群外部域名自身异常

问题原因

上游服务器返回记录显示域名异常。

问题现象

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

解决方案

检查CoreDNS DNS查询请求日志。

常见请求日志
CoreDNS接收到请求并回复客户端后会打印一行日志,示例如下:
# 其中包含状态码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
关于返回码RCODE定义的具体信息,请参见规范
返回码RCODE 含义 原因
NXDOMAIN 域名不存在 容器内请求域名时,会被拼接上search后缀,若拼接的结果域名不存在,则会出现该请求码。如果确认日志中请求的域名内容存在,则说明存在异常。
SERVFAIL 上游服务器异常 常见于无法连接上游DNS服务器等情况。
REFUSED 拒绝应答 常见于CoreDNS配置或集群节点/etc/resolv.conf文件指向的上游DNS服务器无法处理该域名的情况,请排查CoreDNS配置文件。

新增Headless类型域名无法解析

问题原因

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

问题现象

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

解决方案

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

StatefulSets Pod域名无法解析

问题原因

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

问题现象

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

解决方案

修改StatefulSets Pod YAML中ServiceName名称。

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

问题原因

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

问题现象

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

解决方案

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

容器网络连通性异常

问题原因

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

问题现象

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

解决方案

运行容器网络诊断。具体操作,请参见通过集群故障诊断功能定位集群问题

CoreDNS Pod负载高

问题原因

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

问题现象
  • 部分节点或全部节点接入CoreDNS的业务,Pod解析域名的延迟增加、概率性或持续性失败。
  • 检查CoreDNS Pod运行状态发现各副本CPU、Memory使用量接近其资源限制。
解决方案
  • 考虑采用NodeLocal DNSCache缓存方案,提升DNS解析性能,降低CoreDNS负载。具体操作,请参见使用NodeLocal DNSCache
  • 适当扩充CoreDNS副本数,使每个Pod的峰值CPU始终低于节点空闲CPU数。

CoreDNS Pod负载不均

问题原因

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

问题现象
  • 部分接入CoreDNS的业务Pod解析域名的延迟增加、概率性或持续性失败。
  • 检查CoreDNS Pod运行状态发现各副本CPU使用量负载不均衡。
  • CoreDNS副本数少于两个,或多个CoreDNS副本位于同节点上。
解决方案
  • 扩容并打散CoreDNS副本到不同的节点上。
  • 负载不均衡时,可禁用kube-dns服务的亲和性属性。具体操作,请参见配置Kube-DNS服务

CoreDNS Pod运行状态异常

问题原因

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

问题现象
  • 部分接入CoreDNS的业务Pod解析域名的延迟增加、概率性或持续性失败。
  • CoreDNS副本状态Status不处于Running状态,或重启次数RESTARTS持续增加。
  • CoreDNS运行日志中出现异常。
解决方案

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

常见异常日志及处理方案
日志中字样 原因 处理方案
/etc/coredns/Corefile:4 - Error during parsing: Unknown directive 'ready' 配置文件和CoreDNS不兼容,Unknown directive代表当前运行的CoreDNS版本不支持ready插件。 从kube-system命名空间中CoreDNS配置项中删除ready插件,其它报错同理。
pkg/mod/k8s.io/client-go@v0.18.3/tools/cache/reflector.go:125: Failed to watch *v1.Pod: Get "https://192.168.0.1:443/api/v1/": dial tcp 192.168.0.1:443: connect: connection refused 日志出现时间段内,APIServer中断。 如果是日志出现时间和异常不吻合,可以排除该原因,否则请检查CoreDNS Pod网络连通性。具体操作,请参见检查CoreDNS Pod的网络连通性
[ERROR] plugin/errors: 2 www.aliyun.com. A: read udp 172.20.6.53:58814->100.100.2.136:53: i/o timeout 日志出现时间段内,CoreDNS无法连接到上游DNS服务器。

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

问题原因

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

问题现象

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

解决方案

Conntrack表满

问题原因

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

问题现象
  • 部分节点或全部节点上接入CoreDNS的业务,Pod解析域名在业务高峰时间段内出现大批量域名解析失败,高峰结束后失败消失。
  • 运行dmesg -H,滚动到问题对应时段的日志,发现出现conntrack full字样的报错信息。
解决方案

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

AutoPath插件异常

问题原因

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

问题现象
  • 解析集群外部域名时,概率性解析失败或解析到错误的IP地址,解析集群内部域名无异常。
  • 高频创建容器时,集群内部服务域名解析到错误的IP地址。
解决方案
关闭AutoPath插件。
  1. 执行kubectl -n kube-system edit configmap coredns命令,打开CoreDNS配置文件。
  2. 删除autopath @kubernetes一行后保存退出。
  3. 检查CoreDNS Pod运行状态和运行日志,运行日志中出现reload字样后说明修改成功。

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

问题原因

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

问题现象
  • 接入CoreDNS的业务Pod解析域名概率性失败。
  • 从抓包或检查CoreDNS DNS查询请求日志可以发现,A和AAAA通常在同一时间的出现,并且请求的源端口一致。
解决方案
  • 考虑采用NodeLocal DNSCache缓存方案,提升DNS解析性能,降低CoreDNS负载。具体操作,请参见使用NodeLocal DNSCache
  • CentOS、Ubuntu等基础镜像,可以通过options timeout:2 attempts:3 rotate single-request-reopen等参数优化。
  • 如果容器镜像是以Alpine制作的,建议更换基础镜像。更多信息,请参见Alpine
  • PHP类应用短连接解析问题较多,如果使用的是PHP Curl的调用,可以使用CURL_IPRESOLVE_V4参数仅发送IPv4解析。更多信息,请参见函数说明

IPVS缺陷导致解析异常

问题原因

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

问题现象

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

解决方案

NodeLocal DNSCache未生效

问题原因
  • 未配置DNSConfig注入,业务Pod实际仍配置了CoreDNS kube-dns服务IP作为DNS服务器地址。
  • 业务Pod采用Alpine作为基础镜像,Alpine基础镜像会并发请求所有nameserver,包括本地缓存和CoreDNS。
问题现象

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

解决方案
  • 配置DNSConfig自动注入。具体操作,请参见使用NodeLocal DNSCache
  • 如果容器镜像是以Alpine制作的,建议更换基础镜像。更多信息,请参见Alpine

PrivateZone域名解析异常

问题原因

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

问题现象

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

解决方案

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