最后解决方案

经过和负责监控的大佬了解，获得了一个可行的方案：在每个pod中新增一个sidecar容器，在容器中部署node_exporter，或者在容器中放个自动查看端口连接数并推送的脚本。
因为node_exporter不支持push监控数据，所以的话如果使用node_exporter，还需要自己做两点：
1.增加计划任务，自动从node_exporter获取需要的指标后，推送到pushgateway或者prometheus
2.如果每个pod都上报全部指标，会造成prometheus里面数据过多，可以考虑过滤上报的数据，只保留需要的
两个监控都加上后经过验证，经过验证，正确的结论是：
在k8s集群环境下，使用node_sockstat_TCP_inuse 加 node_sockstat_TCP6_inuse 加 node_sockstat_TCP_tw 加 node_sockstat_TCP_orphan这样的指标才能获取到所有容器的连接数。
node_tcp_connection_states指标只能看到宿主机的连接数，看不到容器中的。

以下的结论是错误的，不过过程和相关的数据可能对大家有帮助，就保留了。
以下的结论是错误的，不过过程和相关的数据可能对大家有帮助，就保留了。
以下的结论是错误的，不过过程和相关的数据可能对大家有帮助，就保留了。

背景

通过现有的监控，发现tcp连接数量异常，超过了65535，初步怀疑可能监控指标不对，于是有了以下分析。

查看监控，发现数值比较高的指标为node_sockstat_TCP_tw，参考一些网上的文档，说这是tcp连接数，但后来发现其实和我们平常所说的连接数意义是不一样的。
登录到服务器上，查看more sockstat，数据和监控是一致的

排查过程

这个时候有一些同学应该已经发现不对了，这里显示的数量不是我们平常说的tcp的网络端口监控，而是socket的监控。后来查看了相关的文档，端口连接数和socket连接数的上限是不一样的。
netstat
我们一般看的端口连接数，上限 65535。使用的命令

netstat -auntlp|grep -i listen|wc -l
prometheus的指标为 node_tcp_connection_states{state="established"} 加 node_tcp_connection_states{state="listen"} 加 node_tcp_connection_states{state="time_wait"}

sockstat
上面监控看到的socket连接数，上限为/proc/sys/fs/file-max和ulimit的值，我们的服务器上是100W。使用命令

more /proc/net/sockstat #查看socket的详细情况
more /proc/sys/fs/file-max #查看系统级最大允许打开的句柄数
ulimit #查看用户级最大允许打开的句柄数
prometheus的指标为 node_sockstat_TCP_inuse 加 node_sockstat_TCP6_inuse 加  node_sockstat_TCP_tw 加 node_sockstat_TCP_orphan

详细的socket和句柄相关的解释，可以参考
张彦飞：刨根问底儿式处理 Too many open files 错误！
设置Linux打开文件句柄/proc/sys/fs/file-max和ulimit -n的区别
综上所述，这也是为什么显示连接数都已经7W+了，服务还没有异常的原因，因为这里监控的是socket连接数，上限是100W。

如何查看UDP连接数
可能是目前我的node_exporter版本较低，目前能看到UDP相关的指标只有node_sockstat_UDP_inuse，和文件系统还有netstat查到的数据是一致的，但是目前看不到udp6的数据,查看新版的node_exporter已经支持了node_sockstat_UDP6_inuse

参考文档：

prometheus node_exporter 监控项
如何排查ss& netstat统计结果不一样的原因？-问答-阿里云开发者社区-阿里云
端口号超过了65535 - 云+社区 - 腾讯云