华为云CCE DNS解析超时排查：CoreDNS故障定位指南

在华为云CCE集群里，业务Pod访问Service或外部域名时偶发超时，很多时候并不是应用代码或容器网络先出问题，而是DNS解析链路在某个环节被拖慢。要真正做好华为云CCE DNS解析超时排查，得先搞清楚CoreDNS在集群内到底承担什么角色，以及一次DNS请求从Pod发出到返回应答中间经过哪些节点。

什么是CoreDNS及其在华为云CCE中的作用

CoreDNS是CNCF毕业的开源DNS服务器，使用Go语言编写，也是Kubernetes默认的集群DNS插件。在华为云CCE环境中，CoreDNS通常以Deployment形式部署在kube-system命名空间下，通过kube-dns这个Service对外提供解析入口。Pod默认采用ClusterFirst DNS策略，也就是说集群内域名和外部域名都会先发给CoreDNS，由它决定直接应答还是转发给上游VPC DNS。解析超时，本质上是CoreDNS或其上游链路在预期时间内没有返回DNS应答，导致业务请求卡在域名解析阶段。

聚搜云在整理这类服务器故障时发现，大多数CCE DNS解析超时并不是CoreDNS进程崩溃或配置完全错误，而是某一段链路响应变慢，比如CoreDNS资源水位过高、上游VPC DNS响应延迟，或者集群网络策略拦截了UDP 53端口流量。理解了这一点，后续排查才不会一上来就盲目重启CoreDNS或改动Corefile。

CoreDNS在CCE中到底承担什么角色？

CoreDNS在CCE集群里相当于一个内部DNS网关，既要解析<service>.<namespace>.svc.cluster.local这类集群内Service域名，也要代理外部域名的递归查询。它维护着集群Service和Pod的DNS记录，一旦CoreDNS不可用或响应变慢，服务发现就会直接失败，表现为应用日志里出现connection reset或i/o timeout。这也是为什么很多团队一开始会误判为业务代码或负载均衡问题。

CCE里Pod的DNS解析请求是怎么走的？

Pod发起DNS请求后，会根据/etc/resolv.conf里的nameserver指向kube-dns的ClusterIP，请求先到达CoreDNS。CoreDNS内部通过插件链处理：集群内域名走kubernetes插件直接返回答案，外部域名则转发给上游DNS，通常指向VPC内网DNS地址，例如100.125.x.x。如果上游DNS响应缓慢，CoreDNS会一直等待，直到超过timeout阈值才返回超时错误。这就是很多解析超时最终定位在上游VPC DNS的原因。

为什么DNS解析会表现为超时而不是直接报错？

DNS超时和解析失败是两回事。解析失败一般会快速返回NXDOMAIN或SERVFAIL，提示记录不存在或配置有问题；而超时是CoreDNS把请求发出去后，在规定时间内没有收到任何应答，客户端只能干等直到自身超时。在实际运维中，如果大量Pod同时出现偶发超时，且CoreDNS Pod本身没有重启，优先怀疑的是上游DNS响应慢、CoreDNS连接数打满或节点网络拥塞，而不是CoreDNS的解析规则写错。

华为云CCE DNS解析超时的常见症状

在华为云CCE集群中，DNS解析超时很少以单一报错形式出现，更多时候它夹杂在业务日志、连接异常和服务发现失败之间。一个典型现象是：Pod内访问Service短域名时，首个请求卡住 5 秒甚至更久，随后返回 could not resolve host 或 connection timed out，但直接使用 Pod IP 或已知的 ClusterIP 访问却正常。这说明网络层本身可达，名称解析环节出现了延迟。运维人员容易把这类现象误判为业务代码问题或 CNI 网络故障，实际抓包后才发现 DNS 请求在 CoreDNS 队列里排队超过 2 秒，或者向上游转发后迟迟没有响应。

一、如何判断DNS超时：用dig和日志定性

判断 DNS 超时不能只看业务日志里的 “timeout”，因为 HTTP 超时、TCP 连接超时和 DNS 解析超时经常混在一起。最直接的方式是在 Pod 内执行带计时的 dig 命令：

time dig @<coredns-svc-ip> kubernetes.default.svc.cluster.local

如果 Query time 超过 1000ms，或者出现 connection timed out; no servers could be reached，基本可以确认 DNS 链路存在问题。CoreDNS 侧可执行 kubectl logs -n kube-system -l k8s-app=coredns --tail=200 | grep -E "i/o timeout|SERVFAIL"，高频 i/o timeout 指向上游 VPC DNS 响应慢，SERVFAIL 则是上游返回否定应答或格式错误。需要明确区分 NXDOMAIN（记录不存在）和真正的超时，两者排查方向完全不同。

二、可能相关的错误信息：从业务日志到CoreDNS日志

不同语言在业务侧留下的报错形式差异较大：Java 应用抛出 java.net.UnknownHostException，Node.js 报 getaddrinfo EAI_AGAIN，Python 常见 socket.gaierror: [Errno -3] Temporary failure in name resolution，Nginx 使用动态域名时可能记录 no resolver defined to resolve xxx。CoreDNS 日志中一条典型的超时记录如下：

[ERROR] plugin/errors: 2 xxx.svc.cluster.local. A: read udp 10.0.0.5:53->100.125.1.1:53: i/o timeout

这条日志直接指向 CoreDNS 向上游 VPC DNS（通常为 100.125.x.x）的 UDP 请求超时。如果 Pod 到 CoreDNS 的 UDP/TCP 53 端口被安全组或 NetworkPolicy 丢弃，CoreDNS 可能完全没有请求记录，但 Pod 侧会表现为 connection refused 或 timeout，需要结合节点安全组规则和网络策略进行排查。

三、确认问题范围：全集群还是局部节点

确认范围是决定后续排查方向的关键。先用 kubectl get pods -A -o wide 查看异常 Pod 是否集中在特定节点。如果全集群范围内偶发超时，优先怀疑 CoreDNS 容量不足或上游 DNS 抖动；如果只集中在某个节点，需要检查该节点到 CoreDNS Pod 的网络路径、kube-proxy 规则或节点自身 DNS 缓存；如果只影响特定应用，则需确认该应用的 DNS 策略是否为 ClusterFirst：

kubectl get pod <pod-name> -n <namespace> -o jsonpath='{.spec.dnsPolicy}'

若策略不是 ClusterFirst，可能绕过了 CoreDNS。此外还需要关注 CoreDNS 副本数与集群实际 Pod 数量的匹配情况，集群扩容后未相应调整 CoreDNS 副本数，也是常见诱因。

CoreDNS解析超时的原因分析

在华为云CCE DNS解析超时排查中，CoreDNS自身异常、资源瓶颈和链路抖动往往交织出现，很少能靠单一调整解决。下面按配置、资源、网络三个维度拆解。

配置问题排查

检查CoreDNS的ConfigMap是最直接的起点。执行kubectl -n kube-system get configmap coredns -o yaml查看Corefile，重点确认forward指向的上游DNS是否正确。如果误配成公网DNS地址，外部域名解析会绕行公网，延迟明显增加；如果未启用cache插件，每次请求都会打到上游，放大超时概率。还要注意ready和health插件是否被误删，导致Pod实际不可用但探针没报错。

资源限制导致超时

CoreDNS用Go实现，单Pod的CPU和内存配额直接影响请求吞吐。当集群Pod数从几十增长到几百，默认两副本且每副本CPU limit只有100m时，高峰期会出现明显排队，表现为业务偶发5秒以上超时。用kubectl top pod -n kube-system | grep coredns查看实时水位，若CPU持续接近limit，说明需要扩副本或提高资源配额，而不是继续改Corefile。

网络链路问题

很多超时最终根因不在CoreDNS，而在上游VPC DNS。Pod默认采用ClusterFirst策略，先访问CoreDNS，再由CoreDNS代询华为云VPC DNS（如100.125.x.x）。当上游DNS响应变慢，CoreDNS日志会刷出大量i/o timeout，但Pod本身并不重启。从华东地区华为云代理商聚搜云整理的运维案例来看，这类场景通过dig @<CoreDNS_Pod_IP> <domain>对比集群内和公网解析延迟，能快速判断是CoreDNS被冤枉还是上游链路真有问题。

手动排查CoreDNS的关键步骤

查看CoreDNS日志

先不要急着改 Corefile，日志是成本最低的判断入口。执行 kubectl logs -n kube-system -l k8s-app=coredns --tail=200，重点过滤 i/o timeout、SERVFAIL、connection refused。从聚搜云接触到的企业运维场景来看，i/o timeout 多数指向 CoreDNS 到上游 VPC DNS（100.125.x.x）的链路响应慢，SERVFAIL 才更多与配置错误有关。广州华为云代理商在 CCE 排障时会先区分这两类错误，因为前者继续调 CoreDNS 参数没有意义，反而会把时间耗在错误方向上。

验证DNS配置

配置检查的重点不是全文通读，而是确认 Corefile 里 forward 上游地址和 cache 行为。执行 kubectl get cm coredns -n kube-system -o yaml，查看 forward . 指向的是 /etc/resolv.conf 还是 100.125.x.x，以及是否与当前 CCE 集群所在的 VPC 网段匹配。聚搜云在整理这类服务器故障时发现，迁移过子网或更换过 VPC 后，残留的旧上游 DNS 地址会造成“集群内域名正常、外部域名偶发超时”的隐蔽现象。还要留意日志中是否出现 loop detected，一旦出现说明 CoreDNS 在向自身转发请求，CPU 和解析超时会同时升高。

使用dig等工具测试

进入业务 Pod 做定向测试，比从节点上 ping 更有说服力。先取 CoreDNS Pod IP：kubectl get pods -n kube-system -l k8s-app=coredns -o wide，然后在 Pod 内执行 dig @<coredns_pod_ip> <service>.<namespace>.svc.cluster.local +short +time=2 +tries=1。如果集群内域名解析正常，再测 dig @100.125.x.x www.huaweicloud.com +time=2 +tries=1。华为云代理商在实际运维中会重点看两次测试的耗时差：前者快、后者超时，基本锁定上游 VPC DNS 链路；两者都慢，则回头查 CoreDNS 资源水位，执行 kubectl top pod -n kube-system | grep coredns 看 CPU、内存是否贴近 limit 值。

解决CoreDNS解析超时的方案

调整CoreDNS副本数

在华为云CCE DNS解析超时排查过程中，调整CoreDNS副本数往往是首先执行的动作。从上海华为云代理商聚搜云整理的运维案例来看，很多CCE集群默认只部署2个CoreDNS副本，当节点数超过50或服务发现请求高频时，单副本的UDP连接数会接近上限，导致偶发解析超时。遇到这种情况，优先用kubectl get pods -n kube-system -l k8s-app=coredns -o wide确认副本分布，再通过kubectl -n kube-system scale deployment coredns --replicas=4提升副本数。副本数不是越多越好，要结合CoreDNS Pod的CPU/内存配额和节点规格，避免引起节点资源争抢。同时建议为CoreDNS配置PodDisruptionBudget，防止节点维护时所有副本同时下线。调整后观察kubectl top pod -n kube-system | grep coredns的负载变化，再决定是否继续扩容。

优化配置参数

副本扩容解决的是吞吐瓶颈，但解析超时也可能来自CoreDNS的转发策略和缓存配置不当。先执行kubectl -n kube-system edit configmap coredns查看Corefile，重点关注forward .上游地址和超时参数。华为云CCE环境中，上游通常指向VPC DNS，若上游响应慢，可以在forward .中显式增加timeout和policy参数，例如forward . 100.125.0.10 { max_concurrent 1000 }，避免默认值在突发流量下排队。cache插件对应答缓存时长有直接影响，服务发现场景可适当提高success缓存时间，降低对上游的反复查询。修改后执行kubectl rollout restart deployment coredns -n kube-system使配置生效，不要只改文件不重启。

升级或重建CoreDNS

如果副本数和配置参数都调整过，仍然出现无规律i/o timeout，就要怀疑当前CoreDNS版本存在并发处理缺陷或插件bug。先通过kubectl -n kube-system get deployment coredns -o yaml确认版本，再决定是否升级。华为云CCE控制台一般提供插件升级入口，升级前务必备份现有ConfigMap和Deployment YAML，方便回滚。如果暂时不能升级，可以执行kubectl delete pod -n kube-system -l k8s-app=coredns让Pod重建，清除可能的goroutine泄漏或连接池异常。重建后持续用kubectl logs -n kube-system -l k8s-app=coredns --tail=200 | grep -E "i/o timeout|SERVFAIL|connection refused"观察，确认问题是否收敛。

如何预防CCE DNS解析超时

监控与告警设置

不要等业务报障才看CoreDNS。建议通过Prometheus采集coredns_dns_request_duration_seconds的P99分位和coredns_dns_requests_total的SERVFAIL计数，设置告警规则：P99解析超过200ms或SERVFAIL比例超过1%时通知。同时监控上游VPC DNS响应时间，避免CoreDNS背锅。用kubectl -n kube-system logs -l k8s-app=coredns --tail=200定期检索i/o timeout、SERVFAIL关键字。

最佳实践建议

按集群规模配置副本数，一般每100节点至少2个CoreDNS副本，并设置明确的CPU/内存limit。Pod数超2000或DNS QPS较高时，优先启用NodeLocal DNSCache，把集群内解析缓存到节点本地。为CoreDNS配置PodDisruptionBudget，避免节点维护时所有副本同时不可用。高并发场景还需调整max_concurrent，防止连接耗尽导致的超时。

定期检查与维护

将CoreDNS纳入周期巡检。升级CCE集群或CoreDNS版本前先在测试环境验证，避免生产解析异常。定期执行kubectl -n kube-system get pods -l k8s-app=coredns -o wide检查Pod分布是否均衡，清理无效转发规则。从业务Pod用dig测试集群内外域名解析，记录基准延迟。关注CoreDNS社区和华为云CCE版本公告，及时修复已知问题。