Kubernetes Pod间歇性发送RST包致502错误排查求助

核心差异定位 #

首先明确关键差异：代码硬编码30秒延迟时服务正常，但通过混沌工具注入相同延迟触发RST包与502错误，说明问题不在应用本身的业务逻辑或基础超时配置，而是混沌工具的注入方式干扰了TCP连接的正常生命周期。

具体排查方向 #

1. 混沌工具的延迟注入机制 #

• 确认工具是在Pod网络层（如iptables规则）还是应用进程内注入延迟：
  • 若为网络层注入，可能导致Tomcat或内核误判连接状态，主动发送RST。检查工具是否修改了TCP内核参数（如tcp_retries2、tcp_keepalive_time），这类参数会直接影响连接的超时重置逻辑。
  • 尝试切换为进程内注入（如Java Agent拦截API方法添加延迟），对比是否仍出现RST问题，验证网络层注入是否为诱因。

2. Nginx Ingress的长连接复用逻辑 #

• 尽管已配置proxy-read-timeout等参数，但Nginx的上游连接池可能复用了已被Tomcat关闭的长连接：
  • 检查Ingress是否启用了上游长连接（默认可能未配置），Tomcat的keep-alive-timeout=60s，若Nginx连接池中的连接闲置超过该时间，Tomcat会主动关闭连接，Nginx复用此连接时就会收到RST。
  • 补充Ingress的长连接对齐配置：

    nginx.ingress.kubernetes.io/proxy-http-version: '1.1'
    nginx.ingress.kubernetes.io/proxy-set-header: "Connection \"keep-alive\""
    nginx.ingress.kubernetes.io/upstream-keepalive-timeout: '60'
    nginx.ingress.kubernetes.io/upstream-keepalive-requests: '200'
    nginx.ingress.kubernetes.io/upstream-keepalive-connections: '400'
    

3. Tomcat连接与线程池状态 #

• 虽然请求频率（50次/分钟）远低于线程池上限（200线程），但混沌延迟可能导致连接处于半开状态占用连接数：
  • 通过Spring Boot Actuator监控tomcat.connections.*、tomcat.threads.*指标，确认是否出现连接数打满（max-connections=400）的情况。
  • 查看Tomcat的AccessLog，记录所有请求的处理状态，确认是否有请求被Tomcat主动拒绝并发送RST。

4. 内核TCP参数的影响 #

• 检查Pod内核的TCP重置相关参数，确认是否内核主动触发RST：
  • 执行sysctl net.ipv4.tcp_abort_on_overflow，若值为1，当Tomcat的accept队列满时，内核会直接发送RST而非丢弃包；即使请求频率低，混沌延迟可能导致队列处理变慢触发该逻辑，建议改为0。
  • 调整tcp_fin_timeout、tcp_rst_timeout参数，避免内核过早回收连接：

    # 在Pod的Deployment配置中添加
    securityContext:
      sysctls:
      - name: net.ipv4.tcp_fin_timeout
        value: "60"
      - name: net.ipv4.tcp_rst_timeout
        value: "60"
      - name: net.ipv4.tcp_abort_on_overflow
        value: "0"
    

验证与修复步骤 #

1. 优先对齐Ingress与Tomcat的长连接配置，部署后重新执行混沌测试，观察是否仍出现RST/502。
2. 若问题依旧，切换混沌工具的注入方式为进程内，验证网络层注入是否为根本原因。
3. 监控Tomcat与内核的连接状态，定位是否存在连接数耗尽或内核主动重置的情况。

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