记参数net.ipv4.tcp_tw_recycle引发的问题

IT那活儿 2024-01-10

1760

点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！

背景介绍

我们产品有一个业务基础模块为X-baseresource,是作为数据资源同步实用,主要是消费KAFKA集群的TOPIC数据。

最近做了防火墙变更，反馈总是有时候数据同步异常，由于我们的业务是在K8S容器，在容器telnet端口不通，但在对应的宿主机端口却是通的，已找了相关的后台维护厂商查看说他们K8S集群正常没有问题，于是有了下面这段分析。

问题分析

2.1 业务模块base-resource报其中有业务模块的POD连接不上KAFKA

2.2 检查是否iptables是否有放通

Iptalbes -n – v -L #检查是已放通防火墙

由于iptables是开启白名单，为保障不是iptables影响，临时性关闭整个白名单，发现还是网络不通。

2.3 业务模块和KAFKA其它节点通信正常

Kafka集群存在有5个节点，这里示例为：25.8 ，25.9，25.41，25.42，25.43。

在k8s pod中 telent 其它节点通信正常，唯独25.41不通。

2.4 其它业务模块与25.41 telnet网络通信正常

2.5 base-resource pod所属集群宿主机与25.41通信正常

2.6 telnet通信正常，traceroute正常，但tcping有no respose未响应

问题处理

3.1 原因总结

Tcping不通，说明TCP连接无法建立成功，在请求中，TCP连接包被丢弃，于是检查KAFKA集群的所有主机，发现41主机net.ipv4.tcp_tw_recycle=1，其它主机为0，

备注：开启后可以快速回收tcp连接中timewait状态的连接，当连接处于TIME_WAIT状态时，会占用2MSL，相同四元组(源地址，源端口，目标地址，目标端口)的连接无法创建，所以有些场景为了尽快释放资源所开启此参数，但是当tcp_timestamps此参数也同时开启时(默认开启)，会针对客户端请求来时的包记录发出时的时间戳进行校验，在有K8S NAT网络中，有可能会丢弃SYN请求包，导致建立TCP连接失败。

3.2 问题解决

对41主机中 vi etc/sysctl.conf修改net.ipv4.tcp_tw_recycle=0。

Sysctl -p 生效，base resource模块pod telnet 41中9092端口恢复正常。

后续总结：

在生产环境中，任何内核参数都有可能影响业务的稳定运行，但本案中net.ipv4.tcp_tw_recycle,修改为1是为了快速解决time_wait的问题，但最终导致了业务故障，这得不偿失，所以要对被修改的参数研究透彻再行整改。

END

本文作者：唐田寿(上海新炬中北团队）

本文来源：“IT那活儿”公众号

ipv4 通信 pod

文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。