问题极可能出在k8s dns链路，需先通过curl -w验证time_namelookup是否远高于time_connect，再对比直连clusterip确认dns瓶颈；接着检查/etc/resolv.conf配置、coredns连通性、pod状态、endpoints、日志及corefile forward插件。
业务接口响应缓慢或超时，但直连服务IP正常，而调用域名时卡在解析阶段，说明问题极可能出在K8s DNS链路——不是容器本身配置错误，而是CoreDNS解析路径中某环出现延迟、丢包或负缓存未清除。
确认是否真为DNS层超时
别急着重启CoreDNS。先进入异常Pod执行带时间度量的curl：curl -w "@curl-format.txt" -o /dev/null http://svc-name.namespace.svc.cluster.local，重点看time_namelookup字段是否远高于time_connect（例如前者12.345s，后者0.012s）。
立即对比直连ClusterIP：curl -w "@curl-format.txt" -o /dev/null http://10.96.123.45。若后者耗时毫秒级，前者十几秒，【基本锁定是DNS解析环节卡住】。
再运行nslookup svc-name.namespace.svc.cluster.local，观察是否卡在“Server:”之后无响应、返回timeout或NXDOMAIN——前者指向网络连通性问题，后者可能是服务未注册或search域不匹配。
检查Pod的DNS配置与基础连通性
执行kubectl exec -it <pod-name> -n <namespace> -- cat /etc/resolv.conf</namespace></pod-name>，确认nameserver行只有一条且指向集群CoreDNS Service IP（如10.96.0.10），【若出现127.0.0.53、多个nameserver或宿主机IP，说明dnsPolicy被覆盖或节点resolv.conf污染】。
检查search域是否包含namespace.svc.cluster.local svc.cluster.local cluster.local，缺任何一个都可能导致短域名解析失败。
用nc -vz 10.96.0.10 53测试UDP端口连通性；若失败，再试TCP：nc -vz 10.96.0.10 53。不通则立刻查kube-proxy状态、CNI插件日志、节点防火墙或云厂商安全组规则。
验证CoreDNS自身健康与上游可达性
第一步：确认Pod状态与Endpoint一致
执行kubectl get pods -n kube-system -l k8s-app=kube-dns，确保所有Pod为Running且READY 1/1；
执行kubectl get endpoints -n kube-system kube-dns，确认ENDPOINTS列有IP且端口为53（UDP/TCP）。
第二步：抓取关键日志线索
运行kubectl logs -n kube-system -l k8s-app=kube-dns --tail=100 | grep -E "(i/o timeout|refused|no upstream|SERVFAIL)"。
若出现forward plugin: no upstream，说明Corefile里forward插件缺失或上游DNS地址不可达；
若大量i/o timeout且集中在upstream，检查CoreDNS所在节点能否ping 8.8.8.8或dig google.com @1.1.1.1。
第三步：核对Corefile配置
执行kubectl get cm coredns -n kube-system -o yaml，确认forward .后跟的是有效上游（如8.8.8.8或节点/etc/resolv.conf中的DNS），【禁用forward . /etc/resolv.conf这种写法，它会继承节点污染的DNS】。
用直连PodIP隔离Service数据面故障
方法一：绕过kube-proxy，定位真实瓶颈
① 获取一个CoreDNS Pod IP：kubectl get pod -n kube-system -l k8s-app=kube-dns -o jsonpath='{.items[0].status.podIP}'
② 在业务Pod内直连查询：kubectl exec -it <pod-name> -n <namespace> -- nslookup kubernetes.default <coredns-pod-ip></coredns-pod-ip></namespace></pod-name>
③ 若②成功但默认解析失败，则问题在kube-proxy规则、conntrack表溢出、NetworkPolicy拦截或CNI转发异常。
方法二：快速复现并比对
起一个临时BusyBox调试Pod：kubectl run -it --rm dns-test --image=busybox --restart=Never -- sh，在其中重复上述nslookup和nc测试，避免业务Pod镜像差异干扰判断。
方法三：检查NodeLocal DNSCache（如已启用）
若集群部署了NodeLocal DNSCache，进入业务Pod执行cat /etc/resolv.conf，确认nameserver是否为169.254.20.10；若不是，说明注入失败，需检查DaemonSet状态及节点污点容忍。
