Kubernetes中Java应用连接Oracle DB时TCP长连接随机销毁问题排查

问题概述 #

迁移Java应用至Kubernetes后，出现外部Oracle数据库长TCP连接被随机销毁的问题：

• 连接建立后，会在30分钟至2天内随机触发java.sql.SQLRecoverableException: IO Error: Connection reset by peer报错
• 仅部分POD受影响，高负载场景下发作更频繁
• 抓包及conntrack日志显示：连接正常运行约18小时后，conntrack于12:27:26标记该连接为[DESTROY]；后续POD复用连接时收到Oracle返回的RST包，节点新映射的端口同样被RST
• 已确认Hibernate会话存在未正常清理的情况，使用Canal作为CNI，重启POD可临时恢复但问题会重复出现

核心排查方向（针对conntrack标记[DESTROY]的原因） #

1. 节点conntrack参数及资源阈值检查 #

• 检查节点TCP已建立连接的超时配置：

  sysctl net.netfilter.nf_conntrack_tcp_timeout_established
  

  默认值为432000秒（5天），若该值被修改为远小于18小时的数值，会直接导致连接超时销毁。
• 检查conntrack表资源是否耗尽：

  # 查看当前conntrack连接数
  conntrack -L | wc -l
  # 查看conntrack最大容量
  sysctl net.netfilter.nf_conntrack_max
  

  若当前连接数接近最大值，高负载时节点会随机清理旧连接以释放资源，这是此类问题的常见诱因。
• 同时检查其他TCP状态的超时参数，确认是否存在异常配置：

  sysctl net.netfilter.nf_conntrack_tcp_timeout_time_wait
  sysctl net.netfilter.nf_conntrack_tcp_timeout_close_wait
  

2. Canal CNI的网络规则排查 #

Canal作为CNI插件，可能自带连接跟踪或超时控制逻辑：

• 检查Canal的配置文件（如集群中的canal-config ConfigMap），确认是否存在覆盖节点默认conntrack参数的配置项，或针对Oracle端口的隐性超时规则
• 查看节点上Canal代理的运行日志，定位12:27:26左右的日志条目，排查是否有主动销毁连接的记录或网络异常
• 确认Canal的网络策略未对出站至Oracle数据库的连接做额外限制

3. Oracle端连接限制验证 #

Oracle端主动断开连接也会触发conntrack标记销毁：

• 检查Oracle的SQLNET.EXPIRE_TIME参数，若设置了非0值，Oracle会定期检测空闲连接并断开
• 查看Oracle用户配置文件（PROFILE）中的IDLE_TIME、CONNECT_TIME参数，确认是否存在连接时长或空闲时长限制
• 检查Oracle告警日志，定位12:27:26左右的记录，确认是否有对应连接的主动断开日志

4. POD网络命名空间异常排查 #

仅部分POD受影响，需排查POD网络命名空间的差异：

• 进入异常POD的网络命名空间（需获取POD的PID）：

  nsenter -t $(kubectl get pod <异常POD名称> -o jsonpath='{.status.containerStatuses[0].pid}') -n
  

  查看该命名空间下的conntrack状态，对比正常POD的差异
• 检查POD所在节点的iptables规则，确认是否存在针对该POD IP的特殊NAT或过滤规则，导致连接被提前销毁

5. Hibernate会话未清理的关联影响 #

已知Hibernate会话未正常清理，会加剧问题发作：

• 未清理的会话会导致连接池中的连接长期处于假活状态，被节点或Oracle判定为空闲连接而销毁
• 高负载时连接池连接被频繁复用，假活连接的问题会集中爆发，导致部分POD出现大量报错

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