tw_recycle引发的故障
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了tw_recycle引发的故障相关的知识,希望对你有一定的参考价值。
参考技术A 因后续的A/B发布需要,在k8s环境中新部署一套程序。在验证过程中发现目前对外提供流量的环境A,(后续简称A)可以正常访问集群外部的nginx。但在新部署的环境B(后续简称B)却无法访问集群外部的nginx(后续简称C)1.发生上诉问题的第一个反应是k8s的其中一个节点与C节点网络不通导致的
查询后发现B中的pod和A中的pod位于同一个node上。此刻的我陷入沉思。尝试进入pod内进行curl
同样的命令不同的结果。在A的pod中直接返回了请求信息,但是在B中却一直等待响应。直至curl超时。思绪全无
尝试在该node节点进行curl。发生了令人震惊的事情。curl不通,直接提示超时。
让我们来分析一波首先Apod若需要访问C则需要通过该node节点的物理网卡于C进行通信。即该node节点与C是能够通信并建立TCP连接的。
2.由于刚刚将生产环境的k8s内核版本升级只4.19.12.怀疑是否是内核版本与网卡兼容性问题导致的。于是乎找了个未升级内核版本的k8s集群,进行模拟验证。发现当pod与C建立连接后,pod所在节点无法与C建立TCP连接。直至pod与C的TCP连接断开。所在节点可以与C建立连接。排查到这里,问题答案似乎呼之欲出。似乎是pod建立了TCP连接占据了
根据上述的问题,怀疑是nginx问题,不是k8s集群问题。故把B的pod流量指向另一节点D上。(D上的nginx与C的nginx完全一致)在Bpod访问D时,手动在node节点curl。发现正常可以访问
由于都是TCP🔗的问题,所以面对google上去搜索了下 TCP 连接超时等关键字发现下面这片文章
https://juejin.im/post/6844903800323473422
文章中指出
SYN 重传,第三次握手被重传了,没有收到服务器放的ACK确认
在服务器上抓包能捕获SYN的请求,那就说明服务器端接收到了请求但是没有回应ACK包,于是想起了以前nat环境下tw_recyle的坑,当多个客户端使用同一个外网IP通过NAT访问内网服务器的时候,服务器如果在内核参数中打开了net.ipv4.tcp_tw_recycle = 1
就有可能导致服务器收到SYN但是不会向客户端发送SYN+ACK包。因为打开recyle参数后会识别这些包的时间戳(net.ipv4.tcp_timestamps = 1),但是nat过来的数据包又因为时间戳有可能不是顺序的,导致服务器认为包不可信而丢弃。
故当我们在使用阿里云的VPC虚拟专网的时候,使用弹性IP接入,一定要注意NAT的问题,在服务器参数上关闭net.ipv4.tcp_tw_recycle。 否则从一个ip来的不同客户端请求很有可能导致大量请求失败
故查看C节点,发现开启了net.ipv4.tcp_tw_recycle = 1参数。
使用下列命令
问题得以解决
⚠️ 该参数在 kernel 的4.12后被移除
以上是关于tw_recycle引发的故障的主要内容,如果未能解决你的问题,请参考以下文章
Android手动回收bitmap,引发Canvas: trying to use a recycled bitmap处理