最后解決方案
經過和負責監控的大佬了解，獲得了一個可行的方案：在每個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 - 雲+社區 - 騰訊雲