背景
因后续的A/B发布需要，在k8s环境中新部署一套程序。在验证过程中发现目前对外提供流量的环境A，（后续简称A）可以正常访问集群外部的nginx。但在新部署的环境B（后续简称B）却无法访问集群外部的nginx（后续简称C）
历程
- k8s集群排查
- nginx排查
- C节点参数排查
排查
k8s集群排查
1.发生上诉问题的第一个反应是k8s的其中一个节点与C节点网络不通导致的
kubectl get pod -n xx -owide |grep aaa
查询后发现B中的pod和A中的pod位于同一个node上。此刻的我陷入沉思。尝试进入pod内进行curl
curl 172.16.0.50:1301
同样的命令不同的结果。在A的pod中直接返回了请求信息，但是在B中却一直等待响应。直至curl超时。思绪全无
image.png
尝试在该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排查
根据上述的问题，怀疑是nginx问题，不是k8s集群问题。故把B的pod流量指向另一节点D上。（D上的nginx与C的nginx完全一致）在Bpod访问D时，手动在node节点curl。发现正常可以访问
C节点排查
由于都是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参数。
使用下列命令
sysctl -w net.ipv4.tcp_tw_recycle=0
问题得以解决
⚠️ 该参数在 kernel 的4.12后被移除
网友评论