直接回答：排查套路：先起调试 Pod（kubectl run debug --image=busybox:1.28）里 nslookup 分三层测——集群内服务名（svc.ns.svc.cluster.local）、集群外域名、直接 dig @ 绕过宿主机。看 CoreDNS Pod 状态与日志（kubectl logs -n kube-system -l k8s-app=kube-dns），错误信息（SERVFAIL、超时、拒绝）直接指方向。

展开解析：高频问题清单：CoreDNS 自身过载——解析 QPS 高时 CPU 打满延迟飙升，症状间歇性超时，对策 HPA 扩副本、调 cache TTL、上 NodeLocal DNSCache（每节点本地缓存代理，消灭 conntrack 表项耗尽与跨节点跳转，大规模集群标配）；上游解析失败——forward 指向的上游 DNS（/etc/resolv.conf 继承）不可达或循环（CoreDNS 把请求转发回自己形成回环，日志有 loop 检测告警）；conntrack 耗尽——UDP DNS 高频短连接撑满节点 conntrack 表，随机丢解析，NodeLocal DNSCache 用 TCP 上行规避；ndots:5 陷阱——默认解析配置下，example.com 会依次尝试 example.com..svc.cluster.local 等 5 个搜索域后才查真域名，QPS 放大数倍，FQDN 末尾加点（example.com.）或调 ndots 解决；网络策略——NetworkPolicy 挡了 53 端口 UDP/TCP；stub domain 配置错——企业内 split DNS 的 Corefile 写错转发规则。监控要点：coredns_dns_request_duration、cache 命中率、Panic 重启次数。变更纪律：Corefile 改动先在测试集群验，coredns 是集群少数“挂了全站瘫”的单点组件。

追问方向：NodeLocal DNSCache 的 HA 如何保证？ndots 与搜索域的完整解析顺序？

（约 490 字）