k8s集群唯独一个节点nodeport不通问题调查

k8s集群唯独一个节点nodeport不通问题调查

背景:

​ 集群3个节点,通过svc暴露了一个nodeport类型的31710端口。对于nodeport类型的端口,理论上可以通过任何一个节点的nodeip+nodeport访问的,但是该环境在实际访问时,31710端口呈现频繁无法访问的问题,且telnet不通。

排查问题:
  1. 查看对应服务的pod、svc、endpoint的状态,未见异常

  2. 查看kube-apiserver组件的状态及日志信息,未发现明显问题

  3. 怀疑问题节点的kube-proxy组件异常,观察发现该节点kube-proxy的pod为running,对比正常节点,日志未发现错误信息。

  4. 通过iptables -S -t nat|grep 31710调查正常节点和异常节点的对于nodeport类型的iptables规则,也未发现异常。

  5. 通过在telnet过程中,用tcpdump工具分别在正常节点和异常节点进行抓包。tcpdump -i eth0 -nn tcp port 31710。结果:正常节点三次握手正常完成,而异常节点三次握手未完成,但是收到了来自客户端的sync包。同时,在异常节点,netstat -s|grep -i listen命令,也发现sync的包drop数目增加。

发现问题:
  • 异常节点不响应客户端的sync握手包
结论:
  • 解决办法:修改内核参数net.ipv4.tcp_tw_recycle参数为0

    #修改配置文件
    $ vim /etc/sysctl.conf
    net.ipv4.tcp_tw_recycle = 0
    #生效
    $ sysctl -p
    

    在修改net.ipv4.tcp_tw_recycle为默认值0后,tcp连接正常了。

问题分析:

对于服务端不响应客户端的sync握手包问题,网上踩坑血泪史很多,直接说结论。net.ipv4.tcp_tw_recycle参数修改为1时,会出现此类问题。搜索网络内核参数优化或者优化服务器连接time_wait过多的文章,十之八九说修改net.ipv4.tcp_tw_recycle参数为1的,事后了解到,客户也是参照此类文章优化过环境。

对于tcp_tw_recycle参数,RFC1323 中有如下一段描述:

An additional mechanism could be added to the TCP, a per-host cache of the last timestamp received from any connection. This value could then be used in the PAWS mechanism to reject old duplicate segments from earlier incarnations of the connection, if the timestamp clock can be guaranteed to have ticked at least once since the old connection was open. This would require that the TIME-WAIT delay plus the RTT together must be at least one tick of the sender’s timestamp clock. Such an extension is not part of the proposal of this RFC.

大概意思是说TCP有一种行为,可以缓存每个连接最新的时间戳,后续请求中如果时间戳小于缓存的时间戳,即视为无效,相应的数据包会被丢弃。

Linux是否启用这种行为取决于tcp_timestamps和tcp_tw_recycle,因为tcp_timestamps缺省就是开启的,所以当tcp_tw_recycle被开启后,实际上这种行为就被激活了,当客户端或服务端以NAT方式构建的时候就可能出现问题,下面以客户端NAT为例来说明:

当多个客户端通过NAT方式联网并与服务端交互时,服务端看到的是同一个IP,也就是说对服务端而言这些客户端实际上等同于一个,可惜由于这些客户端的时间戳可能存在差异,于是乎从服务端的视角看,便可能出现时间戳错乱的现象,进而直接导致时间戳小的数据包被丢弃。如果发生了此类问题,具体的表现通常是是客户端明明发送的SYN,但服务端就是不响应ACK。

参数默认状态作用条件影响风险建议
net.ipv4.tcp_timestamps开启记录TCP报文的发送时间双方都要开启影响客户端服务端开启
net.ipv4.tcp_tw_recycle关闭 4.1内核已删除把TIME-WAIT状态超时时间设置为成rto,以实现快速回收要启用net.ipv4.tcp_timestamps影响客户端服务端tcp_tw_recycle和tcp_timestamps同时开启的条件下,60s内同一源ip主机的socket connect请求中的timestamp必须是递增的,否则数据会被linux的syn处理模块丢弃内网环境切没有NAT的时候看情况打开,没什么必要就不要打开了
net.ipv4.tcp_tw_reuse关闭TIME-WAIT状态1秒之后可以重用端口要启用net.ipv4.tcp_timestamps影响客户端

在4.12之后的内核已移除tcp_tw_recycle内核参数(https://github.com/torvalds/linux/commit/4396e46187ca5070219b81773c4e65088dac50cc)。

参考:https://www.tqwba.com/x_d/jishu/289849.html

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值