我在一个名为
kube-proxy的长期过程中遇到了一个问题,它是
Kubernetes的一部分.
问题是连接有时会处于FIN_WAIT2状态.
$sudo netstat -tpn | grep FIN_WAIT2 tcp6 0 0 10.244.0.1:33132 10.244.0.35:48936 FIN_WAIT2 14125/kube-proxy tcp6 0 0 10.244.0.1:48340 10.244.0.35:56339 FIN_WAIT2 14125/kube-proxy tcp6 0 0 10.244.0.1:52619 10.244.0.35:57859 FIN_WAIT2 14125/kube-proxy tcp6 0 0 10.244.0.1:33132 10.244.0.50:36466 FIN_WAIT2 14125/kube-proxy
这些连接随着时间的推移而堆积起来,使得该过程行为不端.我已经reported an issue到Kubernetes bug-tracker但我想了解为什么这样的连接没有被Linux内核关闭.
根据其documentation(搜索tcp_fin_timeout),FIN_WAIT2状态下的连接应在X秒后由内核关闭,其中X可以从/ proc读取.在我的机器上,它设置为60：
$cat /proc/sys/net/ipv4/tcp_fin_timeout 60
所以,如果我理解正确,这样的连接应该关闭60秒.但事实并非如此,他们在这种状态下待了好几个小时.
虽然我也明白FIN_WAIT2连接非常不寻常(这意味着主机正在等待连接的远端可能已经消失的某些ACK)我不明白为什么这些连接没有被系统“关闭” .
我有什么可以做的吗？
请注意,重新启动相关过程是最后的手段.
