文档中心

容器服务

请输入

域名解析（DNS）

CoreDNS 常见问题

集群内域名解析失败（nslookup kubernetes.default.svc.cluster.local），如何排障？

当nslookup kubernetes.default.svc.cluster.local解析失败时，建议按以下顺序排查：

先确认业务 Pod 的/etc/resolv.conf 配置，是否指向正确的集群 DNS（kube-dns/NodeLocal DNS）。

再检查 kube-dns Service 是否可达、CoreDNS Pod 是否就绪且无异常重启。

若 Pod 到 kube-dns 的链路不通，优先排查 DNS 接入路径（网络/路由/策略），不要直接从上游 DNS 入手。”

遇到 NXDOMAIN/no such host，一定是 CoreDNS 故障了吗？

不一定。NXDOMAIN 更常见表示“请求的域名不存在或当前时刻不可解析”。建议按以下顺序排查：

域名拼写是否正确、命名空间是否正确、是否使用了完整 FQDN。

如果访问的是 Headless Service，还需要确认对应的 Endpoints 已生成且处于就绪状态。

如果以上均正常后，再结合 CoreDNS 日志判断是否为解析链路故障。

遇到 i/o timeout/no servers could be reached，如何排障？

这类报错通常表示 DNS 请求在超时时间内没有收到响应，建议按以下顺序排查：

确认从业务 Pod 到 kube-dns/NodeLocal DNS 的连通性。

CoreDNS 进程是否健康、负载是否过高。

确认从 CoreDNS 到上游 DNS 的连通性与转发配置。

确认节点网络、kube-proxy、CNI、网络策略/安全组等可能影响 UDP/TCP DNS 的因素。

仅外部域名解析失败（集群内正常），如何排障？

这通常意味着 CoreDNS 对集群内 Service 的解析仍然正常，但在将请求转发到上游 DNS 时出现异常。建议重点检查：节点出网是否正常、上游 DNS 是否可达且响应稳定、CoreDNS 的转发配置（forward/代理）是否符合预期，以及节点侧的 DNS 配置是否被其他组件覆盖。

仅高峰期出现 DNS 异常，如何排障？

高峰期出现问题，更常见的原因是 DNS 请求量被放大（例如短连接导致频繁解析、ndots/search 配置带来多次重试），而不是简单的“CoreDNS 性能不够”。建议先评估客户端侧请求模式与 ndots/search 的配置影响，并确认是否适合启用 NodeLocal DNS 缓存。在此基础上，再决定是否需要增加 CoreDNS 副本或调整资源。

启用 NodeLocal DNS 后仍异常，如何排障？

常见原因包括：

业务 Pod 并未真正使用 NodeLocal DNS 的本地监听地址（未注入或未生效）。

NodeLocal DNS 在问题节点上未就绪或不健康。

故障原因不在缓存层，而在上游 DNS、节点网络，或客户端请求模式本身。

增加 CoreDNS 副本，是否能解决所有 DNS 超时问题？

不能。扩容 CoreDNS 只能缓解“CoreDNS 自身处理能力不足”这类场景；如果根本原因是 ndots/search 导致请求放大、节点侧 UDP 会话/转发问题、NodeLocal DNS 缺失或上游 DNS 响应慢等，单纯扩副本通常只能降低发生概率，无法彻底消除问题。建议先定位瓶颈点，再选择对应手段。

HPA 是否适合作为 CoreDNS 的默认扩缩容方案？

不建议作为默认方案。CoreDNS 压力不只受 CPU 影响，还与缓存命中率、上游 DNS 响应质量、客户端请求模式等因素强相关。更稳妥的做法是结合观测数据（请求量、超时率、缓存命中、上游延迟）设置人工扩容基线，并预留一定冗余。

如何判断是否需要把问题升级到网络/平台侧排查？

满足以下任一条件时，建议同步升级到网络/平台侧共同定位：

Pod 到 kube-dns Service 不通。

NodeLocal DNS/CoreDNS 在问题节点上不健康。

节点诊断已经提示 DNS、网络或 CNI 异常。

只有某些节点、某些子网、某类工作负载持续异常。

CoreDNS 到上游 DNS 的连通性不稳定。

最近更新时间：2026.08.17 17:04:16

这个页面对您有帮助吗？

有用

无用