Pod中curl超时问题解析

当Pod内执行curl命令访问服务名出现数秒卡顿后失败，而直接使用ClusterIP却能瞬时成功时，问题往往并非网络连通性或后端服务异常，而是DNS解析阶段发生了服务发现链路中断——从ndots配置引发的域名解析膨胀、CoreDNS自身宕机或日志中频繁的i/o timeout，到NetworkPolicy误阻UDP 53端口、CoreDNS无法连通上游DNS，再到kube-proxy规则缺失导致无法访问CoreDNS Service，每一个环节都可能成为“看不见的瓶颈”。本文系统梳理了五大关键排查维度，帮你快速定位并解决Kubernetes中看似随机实则可追溯的DNS超时顽疾。

如果您在 Pod 内执行 curl http://other-service:8080 出现数秒卡顿后失败，而直接使用 ClusterIP（如 curl http://10.96.123.45:8080）可瞬时成功，说明 TCP 连通性与后端服务本身均正常；真正阻塞发生在 DNS 解析阶段。执行 nslookup other-service 返回 NXDOMAIN 或超时，表明 CoreDNS 未返回 A 记录——这不是“慢”，而是服务发现链路中断。以下是解决此问题的步骤：

一、验证 Pod 的 /etc/resolv.conf 配置与 ndots 行为

Pod 默认使用 ndots:5 策略，导致短域名（如 other-service）会先尝试拼接 5 次搜索域后发起解析，极大增加 DNS 查询轮次与延迟，尤其在上游 DNS 不稳定时易触发超时。

1、进入目标 Pod 执行：kubectl exec -it -- cat /etc/resolv.conf

2、确认是否存在 search 行及 ndots:5 字样

3、临时绕过 ndots 行为，使用完整 FQDN 测试：curl http://other-service.default.svc.cluster.local:8080

4、若完整域名可立即成功，则证实为 ndots 导致的解析膨胀问题

二、检查 CoreDNS Pod 状态与日志

CoreDNS 是集群内 Service 名称解析的唯一权威来源，其不可用或高延迟将直接导致所有 Pod 的 DNS 请求超时或返回 SERVFAIL。

1、确认 CoreDNS Pod 是否全部 Running：kubectl get pod -n kube-system -l k8s-app=kube-dns

2、检查任一 CoreDNS Pod 日志中是否存在批量 i/o timeout 或 plugin/errors：kubectl logs -n kube-system

3、若日志中频繁出现 read udp ...: i/o timeout，说明 CoreDNS 无法向上游 DNS（如宿主机 resolv.conf 中配置的 114.114.114.114）发起有效查询

4、验证 CoreDNS 自身网络连通性：kubectl exec -n kube-system -- nslookup kubernetes.default.svc

三、确认 NetworkPolicy 是否阻断 DNS 流量

DNS 查询默认使用 UDP 53 端口（部分场景回退至 TCP 53），若 NetworkPolicy 未显式放行该端口，Pod 将完全无法与 CoreDNS 通信，表现为持续 read udp ...: i/o timeout。

1、列出当前命名空间下所有 NetworkPolicy：kubectl get networkpolicy -n

2、检查每条策略的 spec.ingress 和 spec.egress 规则，确认是否允许目标端口：port: 53, protocol: UDP

3、特别关注 egress 规则：若策略仅允许特定出口（如仅允许 443），则 DNS 请求会被静默丢弃

4、临时禁用可疑 NetworkPolicy 进行验证：kubectl delete networkpolicy -n

四、验证 CoreDNS 与上游 DNS 的连通性

CoreDNS 需将非集群内域名（如 www.baidu.com）转发至上游 DNS 服务器。若其无法访问上游（如被宿主机防火墙、VPC 安全组或 iptables DROP 规则拦截），则外部域名及跨命名空间 Service 均会解析失败。

1、进入 CoreDNS Pod：kubectl exec -n kube-system -it -- sh

2、测试对上游 DNS 的 UDP 连通性：echo "test" | nc -u -w 2 114.114.114.114 53

3、若无响应，检查宿主机 iptables 是否拦截：iptables -t filter -L OUTPUT -n | grep :53

4、检查节点安全组规则是否放行出方向 UDP 53 到上游 DNS IP

五、检查 kube-proxy 是否异常影响 DNS 服务发现

虽然 DNS 解析本身不依赖 kube-proxy，但 CoreDNS Service 的 ClusterIP（如 10.96.0.10）需通过 kube-proxy 的 iptables/IPVS 规则实现负载均衡。若 kube-proxy 异常，Pod 将无法访问 CoreDNS Service IP，导致所有解析请求超时。

1、确认 kube-proxy Pod 状态：kubectl get pod -n kube-system -l k8s-app=kube-proxy

2、检查其日志中是否存在 syncProxyRules 失败或 timeout 关键字：kubectl logs -n kube-system

3、验证节点上是否生成了对应 CoreDNS Service 的 iptables 规则：iptables -t nat -S | grep 10.96.0.10

4、若规则缺失或为空，重启 kube-proxy：kubectl delete pod -n kube-system -l k8s-app=kube-proxy

到这里，我们也就讲完了《Pod中curl超时问题解析》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！