K8s内部网络疑似阻塞，Pod连接RMQ周期性超时失败求助

1. 先盯紧RMQ实例本身的状态 #

• 用kubectl describe pod <rmq-pod-name>查看Pod事件，确认是否存在周期性重启、OOM被终止、节点调度的记录，这类情况会直接导致连接中断
• 持续执行kubectl top pod <rmq-pod-name>监控CPU、内存使用率，若每隔1分钟出现资源尖峰，大概率是RMQ资源不足，暂时无法响应新连接
• 实时查看RMQ日志：kubectl logs <rmq-pod-name> -f，重点关注连接失败时段的日志，排查是否有连接数耗尽、端口监听中断、内部进程重启的报错信息

2. 排查K8s内部网络的周期性波动 #

• 在微服务Pod内持续ping RMQ的PodIP或ClusterIP，同时执行sudo tcpdump -i any host <rmq-pod-ip>抓包，确认是否每隔1分钟出现丢包、延迟飙升的情况
• 确认两个Pod是否在同一节点：若跨节点部署，检查CNI插件（如Calico、Flannel）是否存在周期性刷新网络策略、隧道异常的问题
• 查看kube-proxy日志：kubectl logs -n kube-system <kube-proxy-pod-name>，排查是否存在周期性更新Endpoint、重建iptables规则的操作，这类操作会导致连接短暂断连

3. 检查连接配置与服务发现的潜在问题 #

• 确认微服务连接RMQ使用的是Service ClusterIP还是直接PodIP：若使用ClusterIP，临时改为PodIP测试，若问题消失，说明kube-proxy的Endpoint同步存在延迟
• 执行kubectl exec <rmq-pod-name> -- rabbitmqctl list_connections查看RMQ连接列表，排查是否有大量闲置连接被周期性清理，导致新连接建立时需要重新初始化资源
• 检查微服务的连接池配置：是否存在连接池过小、CreateConnection()未设置超时的情况？未设置超时会导致请求在网络波动时僵住20秒，需添加合理的超时（如5秒）和重试逻辑

4. 排查节点底层的资源异常 #

• 查看RMQ所在节点的内核日志：kubectl exec <rmq-pod-name> -- dmesg，排查是否存在磁盘IO过高、网卡中断、内核参数被周期性调整的记录
• 检查节点的iptables/防火墙规则，确认是否存在周期性更新导致RMQ端口被临时屏蔽的情况
• 执行kubectl top node <rmq-node-name>查看节点负载，排查是否有其他Pod每隔1分钟占用大量资源，拖垮RMQ的网络响应

临时规避方案（管理员无法协助时） #

• 给微服务的CreateConnection()添加超时和重试机制：设置5秒超时，失败后自动重试，避免请求长时间阻塞
• 改用RMQ的Headless Service，直接解析到PodIP，绕开kube-proxy的转发环节
• 若存在多个RMQ实例，配置微服务同时连接多个节点，实现故障转移，降低单节点异常的影响

内容的提问来源于stack exchange，提问作者Ramayasket