NodeLocal DNSCache延迟高时，不要先重启 CoreDNS。更可靠的做法是先确认影响范围：是单个 Pod、单个节点、某类域名，还是全局 DNS 链路都慢。NodeLocal DNSCache 的作用是让节点本地缓存 DNS 查询，减少 Pod 到 CoreDNS Service 的网络跳转；但缓存本身、节点网络和上游 CoreDNS 都可能成为问题来源。
如果你需要先理解集群网络基础，可以参考站内 容器网络 相关内容；本文聚焦 DNS 缓存链路的排查。
图1：从 Pod 解析慢到节点缓存、CoreDNS 和上游转发
先确认 NodeLocal DNSCache 延迟高影响范围
排障第一步不是改配置，而是把问题定位到哪一段链路。
建议先执行：
kubectl get pods -n kube-system -l k8s-app=node-local-dns -o wide
kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide
kubectl exec -n default deploy/sample-app -- nslookup kubernetes.default.svc.cluster.local
kubectl exec -n default deploy/sample-app -- cat /etc/resolv.conf重点看三个信号：Pod 的 `resolv.conf` 是否指向本地 DNS 地址，node-local-dns Pod 是否在问题节点运行，CoreDNS 是否在同一时间出现错误或延迟上升。根据 Kubernetes NodeLocal DNSCache 官方文档，NodeLocal DNSCache 通过在每个节点运行 DNS 缓存代理来改进 DNS 查询路径，具体地址和部署方式应以集群配置为准。
缓存命中低通常说明查询模式或配置有问题
NodeLocal DNSCache 不等于所有查询都会变快。如果业务大量查询带随机前缀的域名、短 TTL 域名或外部域名，缓存命中率可能很低。此时延迟高不一定是缓存组件故障，而是查询模式本身不适合缓存。
图2：Pod 查询、节点本地缓存、CoreDNS 转发和外部
常见根因包括：
- 本地缓存未生效：Pod 仍然直接访问 kube-dns Service。
- 缓存命中率低：查询域名变化大、TTL 太短或搜索域展开过多。
- CoreDNS 上游慢：本地缓存未命中后，上游解析耗时仍然高。
- 节点网络异常：问题只集中在少数节点，伴随丢包或 conntrack 压力。
- 配置回退失败：node-local-dns 配置变更后没有正确转发到 CoreDNS。
如果你看到 CoreDNS QPS 明显升高，先确认是否是缓存绕过，而不是马上扩容 CoreDNS。
CoreDNS排查要看日志、插件和上游转发
CoreDNS 是 Kubernetes DNS 链路中的关键组件。根据 CoreDNS 官方文档，CoreDNS 通过插件链处理查询，Kubernetes 场景通常包含 kubernetes、cache、forward 等插件。排查时要看具体插件和上游行为，而不是只看 Pod 是否 Running。
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=100
kubectl get configmap coredns -n kube-system -o yaml
kubectl top pods -n kube-system重点检查：
- CoreDNS 是否出现 `SERVFAIL`、`timeout`、`no such host` 等错误。
- Corefile 是否存在不合理的 forward 上游配置。
- CoreDNS 副本是否分布在不同节点，避免单点拥塞。
- 是否近期修改过 stubDomains、上游 DNS 或集群域名。
对于生产环境，不建议在没有回滚方案时直接大改 Corefile。可以先在测试集群复现，或通过灰度方式调整上游配置。
节点问题通常表现为局部慢和偶发超时
如果只有某几个节点上的 Pod 解析慢，应把重点从 CoreDNS 转向节点。NodeLocal DNSCache 运行在节点本地，节点 CPU、网络、iptables、conntrack 和本地 DNS Pod 状态都会影响解析。
| 现象 | 可能原因 | 优先动作 |
|---|---|---|
| 单节点所有 Pod 慢 | node-local-dns 异常或节点网络问题 | 查看本地 DNS Pod 日志和节点事件 |
| 只有某类域名慢 | 上游 DNS 或搜索域展开过多 | 对比内部域名和外部域名耗时 |
| 间歇超时 | conntrack、丢包或上游不稳定 | 看节点网络和 CoreDNS 日志时间线 |
| CoreDNS 压力高 | 缓存绕过或命中率低 | 检查 Pod resolv.conf 和缓存指标 |
跨节点验证能区分局部问题
表格只是缩小方向，真正修复前还要做验证。比如把同一个镜像 Pod 调度到不同节点，对比 `nslookup` 耗时，能快速判断是否为节点局部问题。
修复后要验证缓存链路和回退路径
DNS 变更影响面很大，修复后要验证缓存链路是否恢复，而不是只看告警消失。
图3：从发现 DNS 延迟、调整缓存或 CoreDNS 配置到
上线前至少检查：
- Pod 的 `resolv.conf` 是否符合预期。
- node-local-dns Pod 是否覆盖所有目标节点。
- CoreDNS 日志是否不再出现集中超时。
- 内部 Service 域名和外部域名解析耗时是否分别恢复。
- 回滚到原 DNS 路径的操作是否已记录。
如果 DNS 变更涉及大范围节点，建议先按节点池或业务命名空间灰度，避免一次性影响所有服务。
小结
NodeLocal DNSCache延迟高不一定是缓存组件本身坏了。排查时先分清影响范围，再看 Pod DNS 配置、本地缓存、CoreDNS 插件、上游 DNS 和节点网络。修复动作要可回退，验证要覆盖内部域名、外部域名和不同节点。
参考资料
常见问题
1. NodeLocal DNSCache延迟高时能不能直接重启 CoreDNS？
不建议作为第一步。若问题只在少数节点，重启 CoreDNS 可能没有效果，还会影响正常查询。应先确认 Pod 是否走本地缓存、问题节点是否集中以及 CoreDNS 日志是否有对应错误。
2. 启用 NodeLocal DNSCache 后 CoreDNS 还需要扩容吗？
可能仍然需要。NodeLocal DNSCache 降低了部分查询压力，但缓存未命中、外部域名和服务发现查询仍可能进入 CoreDNS。是否扩容要看 QPS、延迟、错误率和副本分布。
3. DNS 缓存命中率低是不是配置错误？
不一定。随机域名、短 TTL、外部 API 域名和大量搜索域展开都会降低命中率。先分析查询模式，再判断是否需要调整应用、DNS 策略或上游配置。
4. 如何验证修复真的有效？
建议在问题 Pod、同节点新 Pod、不同节点 Pod 中分别执行解析测试，并对比 CoreDNS 日志和 node-local-dns 日志。只看单次 `nslookup` 成功不够，还要观察一段时间的超时和延迟趋势。
