日常客服：Caused by: java.net.ConnectException: Cannot assign requested address (connect failed)
前几天收到一个项目组同事反馈，说是应用有异常处理不了业务逻辑，Pod日志有大量以下报错。
Caused by: java.net.ConnectException: Cannot assign requested address (connect failed)
Caused by: java.net.ConnectException: Cannot assign requested address (connect failed)
Caused by: java.net.ConnectException: Cannot assign requested address (connect failed)
Caused by: java.net.ConnectException: Cannot assign requested address (connect failed)
...
应用同事是带着处理方案来找我的，问我怎么优化容器的内核参数，显然是知道这个报错在Linux上的表象是什么了。
这个Java错误日志，网上搜一下会有很多相关文章，分析的原因基本都是：
客户端频繁的起TCP连接，并且每次连接都在很短的时间内结束，导致出现很多的
TCP TIME_WAIT状态，以至于耗尽本地可用源端口，新的连接就不再有可用源端口，因此应用就会抛出这个报错。
建议的处理方案也基本都是启用net.ipv4.tcp_tw_reuse/net.ipv4.tcp_tw_recycle
net.ipv4.tcp_tw_reuse = 1 # 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭
net.ipv4.tcp_tw_recycle = 1 # 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭
net.ipv4.tcp_fin_timeout = 30 # 修改系統默认的TIMEOUT时间，默认是60
net.ipv4.ip_local_port_range = 32768 60999 # 修改本地源端口可用范围
项目组的同事也是询问我怎么在容器里改这几个参数的，乍一看挺有道理的。
不过看到要开启tcp_tw_reuse/tcp_tw_recycle我就心里一紧，K8s可是NAT环境啊，几年前曾经因为在NAT环境启用这两参数导致丢包问题跟踪了好几个月...
稍微回顾一下：
大概是在NAT环境里，当多个客户端通过NAT方式与服务端交互时，服务端看到的是同一个IP，也就是说对服务端而言这些客户端实际上等同于一个，但由于这些客户端的时间戳可能存在差异；因此在服务端看来就是客户端的时间戳错乱了，进而直接导致时间戳小的数据包被丢弃。具体的表现通常是是客户端明明发送的SYN，但服务端就是不响应ACK。
并且在高版本的内核，tcp_tw_recycle默认值是2了，可以简单理解为Linux内核弃用这个参数了。
因此在我们的环境是不能直接修改这几个内核参数的，我们更希望查一下应用报错的具体原因，比如说是否真的源端口在极短耗尽时间内耗尽了；若是，是否真的是应用正常的业务逻辑需要并发启用大量的短链接。
遇到问题，需要先理清楚原因，再去处理问题或者优化问题。
排查过程
应用同事反馈这个问题的时候已经把环境切走了，所有没有现场环境排查。据反馈UAT环境没有复现这个问题，需要现场环境的话得要还原环境及得下一个业务周期。这也说明了应用同事应对问题的手段非常丰富！
没有现场环境，我们就先查了一下集群节点的监控，把所有节点那段时间段内的tcp_tw监控都看了一遍，都是处于较低水位，没什么异常。
同时也想到很多net*类的内核参数都属于namespaced级别的，比如net.ipv4.ip_local_port_range，所以单看节点层级的监控可能并不一定具有很大的参考价值，所以跟应用同事约定一起排查现场环境。
当恢复环境后，我们进入应用容器的net namespace，简单看一下tcp连接状态，看起来也正常
# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
ESTABLISHED 26
TIME_WAIT 87
然后就是触发业务逻辑，然后再看tcp连接状态就发现在极短时间内TIME_WAIT数量超过了2w
# ss -nat |grep TIME-WAIT|wc -l
23988
到这里问题就比较清楚了，应用的报错是有效的，确实是本地源端口在极短耗尽时间内耗尽了。耗尽的原因是：
- 本地可用源端口数量是
2w8左右（默认配置）- net.ipv4.ip_local_port_range = 32768 60999
- 应用大量并发启用短链接
处理方案
知道了问题，处理起来就相对简单了。
- 把排查到的结果反馈给应用同事，让应用同事排查业务代码，看看是不是代码里new连接异常了或者有循环了。
- 如应用正常的业务逻辑需要并发启用大量的短链接，那就需要优化参数了，比如
- net.ipv4.ip_local_port_range = 1024 65535
说到优化容器内核参数，K8s支持不需要使用特权就可以设置部分Sysctl Parameters，官方定义为Safe Sysctls，在workload yaml加入以下内容即可，有兴趣的可以阅读一下K8s官网。
securityContext:
sysctls:
- name: net.ipv4.ip_local_port_range
value: "1024 65535"
干K8s运维也有些日子了，处理过很多K8s上的问题，好像到最后都是Linux的问题。
