治理措施，将物理机和pod容器的参数设置为:
# ip port调大
net.ipv4.ip_local_port_range='1024 65535'
# 连接复用
net.ipv4.tcp_tw_reuse='1'
# 连接回收
net.ipv4.tcp_tw_recycle='1'
# fin超时控制
net.ipv4.tcp_fin_timeout='10'
# tcp keep alive
net.ipv4.tcp_keepalive_time='1800'
net.ipv4.tcp_keepalive_probes='3'
net.ipv4.tcp_keepalive_intvl=15
net.core.netdev_max_backlog='262144'
# time wait最大数量
net.ipv4.tcp_max_tw_buckets='10000'
# sync cookie
net.ipv4.tcp_syncookies='1'
net.ipv4.tcp_max_syn_backlog='1024'
net.ipv4.tcp_synack_retries='2'
net.ipv4.tcp_syn_retries='1'
背景
centos默认的ip端口数是28231，并不是很大，容易堆满。因为timewait数堆积也过大，会造成go http连接池创建不了连接，go协程出现泄漏。
pod默认端口数:
查看timewait数：
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
timewait出现34922，过大，已超过端口数：
go协程池出现突展，程序宕机:
timewait是tcp/ip的客户端主端关闭连接造成，继而排查程序中使用http的地方，在去除反作弊之后，timewait数迅速下降到588，得出结论由反作弊的context超时关闭了客户端的http连接，出现timewait。
定位问题除主要问题是反作弊超时，需要扩容外，pod的连接没有回收也是主要原因。
2.治理措施
将pod和物理机都设置开头的优化参数后，timewait固定在1万以下，不再出现连接打满的情况。
目前 在一天流量最高峰时 96k不再宕机，协程稳定，效果比较明显。
