服务访问延迟高但 Pod 的 CPU/内存使用率正常

一、可能存在的网络问题

当服务访问延迟高但 Pod 的 CPU/内存使用率正常时，问题通常集中在 网络层 或 应用外部依赖。以下是可能的网络问题分类：

1. 集群内部网络问题

• 跨节点通信延迟：Pod 分布在不同的节点，节点间网络链路存在延迟或丢包。

• CNI 插件异常：如 Calico/Flannel 配置错误，导致路由转发效率低下。

• Service/IPVS 负载均衡性能问题：kube-proxy 的负载均衡规则导致流量路径复杂。

2. 跨可用区/区域通信

• 跨可用区流量延迟：Pod 或服务分布在多个可用区（Availability Zone），跨区通信因物理距离增加延迟。

• 云厂商内部网络拥塞：云平台底层网络链路负载过高。

3. DNS 解析延迟

• DNS 查询缓慢：CoreDNS 或外部 DNS 服务器响应时间过长。

• DNS 缓存失效：频繁的 DNS 查询未命中缓存。

4. 外部依赖问题

• 数据库/第三方 API 响应慢：下游依赖服务（如 MySQL、Redis）的网络延迟高。

• 外部服务限流：调用的外部 API 因限流或配额不足导致延迟。

5. 应用层协议问题

• HTTP 连接池不足：客户端未复用 TCP 连接，频繁建立新连接。

• TLS 握手耗时：证书链过长或加密算法复杂。

---

二、系统化排查步骤

1. 初步定位问题范围

• 测试集群内访问延迟： 在集群内启动临时 Pod，直接访问目标服务的 ClusterIP，排除 Ingress/外部流量影响：

  kubectl run -it --rm --image=curlimages/curl test-pod -- \
    curl -w "DNS解析耗时: %{time_namelookup}s\n连接耗时: %{time_connect}s\n总耗时: %{time_total}s\n" http://<service-cluster-ip>

  • 如果延迟高，问题在集群内部；否则排查外部链路。

2. 排查集群内部网络

2.1 检查节点间网络质量

• 在 Pod 所在节点执行 ping 或 mtr 测试跨节点通信：

  # 查看 Pod 所在节点
  kubectl get pod <pod-name> -o wide
  ​
  # 在节点 A 上测试到节点 B 的延迟
  ping <node-B-ip>
  mtr -r -c 10 <node-B-ip>

  • 若节点间延迟高，可能原因：

    • 云厂商底层网络问题（提交工单排查）。

    • 节点负载过高（检查网卡带宽使用：iftop -i eth0）。

2.2 检查 CNI 插件状态

• 查看 CNI 插件（如 Calico）的日志：

  kubectl logs -f <calico-pod-name> -n kube-system

  • 常见问题：路由表未正确同步、IP 池耗尽。

2.3 检查 kube-proxy 和 Service 配置

• 确认 Service 的 Endpoints 正确：

  kubectl describe service <service-name>
  kubectl get endpoints <service-name>

• 检查 kube-proxy 模式（iptables 或 IPVS）：

  kubectl get pods -n kube-system -l k8s-app=kube-proxy -o yaml | grep mode

  • IPVS 性能通常优于 iptables，可考虑切换模式。

3. 排查跨可用区/区域通信

• 确认 Pod 分布：

  kubectl get pods -o wide | grep <service-name>

  • 若 Pod 跨可用区，调整反亲和性策略或使用拓扑感知路由（Topology-aware Routing）。

4. 排查 DNS 解析延迟

• 测试 DNS 解析时间：

  kubectl run -it --rm --image=curlimages/curl test-pod -- \
    curl -w "DNS解析耗时: %{time_namelookup}s\n" http://<service-name>

• 检查 CoreDNS 性能：

  • 查看 CoreDNS 日志和监控指标（如 QPS、延迟）：

    kubectl logs -f <coredns-pod-name> -n kube-system

5. 排查外部依赖

• 直接访问外部服务： 在集群内测试访问数据库或 API 的延迟：

  kubectl run -it --rm --image=curlimages/curl test-pod -- \
    curl -w "总耗时: %{time_total}s\n" http://<external-service-url>

  • 若延迟高，联系外部服务提供方或优化查询逻辑。

6. 应用层协议分析

• 抓包分析： 在客户端或服务端 Pod 抓包，分析 TCP 握手、TLS 协商、HTTP 请求耗时：

  kubectl exec -it <pod-name> -- tcpdump -i eth0 -w /tmp/capture.pcap

  • 使用 Wireshark 分析抓包文件，关注重传（Retransmission）、窗口大小（Window Size）等。

---

三、优化建议

1. 减少跨可用区流量

   • 使用 podAntiAffinity 将 Pod 调度到同一可用区。

   • 启用拓扑感知路由（Topology-aware Routing）。

2. 优化 DNS 解析

   • 调整 CoreDNS 缓存时间（cache 插件配置）。

   • 使用 NodeLocal DNS Cache 减少 DNS 查询延迟。

3. 调整应用协议

   • 使用 HTTP/2 或 gRPC 减少连接开销。

   • 启用 TLS 会话复用（Session Resumption）。

4. 升级网络基础设施

   • 切换为高性能 CNI 插件（如 Cilium）。

   • 使用云厂商的全球加速服务（如 AWS Global Accelerator）。

---

四、工具总结

工具/命令	用途
curl -w	测量 HTTP 请求各阶段耗时
mtr	诊断节点间网络路径和丢包
tcpdump	抓包分析网络交互细节
kubectl describe	查看 Service/Endpoints 配置
kubectl logs	检查 CNI 插件、CoreDNS 日志
iftop	监控节点网卡带宽使用情况

通过以上步骤，可系统化定位并解决高延迟问题。若问题仍无法解决，建议结合 APM 工具（如 SkyWalking）进一步分析应用链路。