問題

目前運維的paas平台,網絡都是基於kube-ovn部署的overlay模式。一次在排查問題時候,發現Pod 中通過 curl 下載集羣外某服務器中的大文件(1GB),出現 connection reset by peer 錯誤導致下載中斷。

雲計算-pod下載外節點大文件時中斷-connection reset by peer_TCP

有時通過瀏覽器,下載一個幾十M文件,也會卡在發起連接的階段。

雲計算-pod下載外節點大文件時中斷-connection reset by peer_Pod_02

排查思路

1、在overlay容器中下載文件,下載到一半報錯連接重置。

2、在宿主機上下載相同文件,正常下載無異常。

雲計算-pod下載外節點大文件時中斷-connection reset by peer_Server_03

3、給容器添加限速10m/s後,也能正常下載,判斷可能為overlay下的網絡性能問題導致。

4、檢查 OVS 日誌,未發現明顯錯誤。

5、檢查主機netstat -s 統計,發現大量 reset 包。

6、通過對 Pod 和節點(node1)物理網卡進行抓包,結果如下(172.29.16.169 為 HTTP Server,10.199.48.86 為 Pod)

雲計算-pod下載外節點大文件時中斷-connection reset by peer_Pod_04

7、從抓包結果來看,第一個異常的 RST 包由 node1 發送給 Server,Server 接收到後發送了 RST 包給節點,node1 將此 RST 包執行 DNAT 轉換後發送給 Pod,導致 curl 出現 connection reset by peer 錯誤。

8、由此推斷,問題出現在 Pod 訪問集羣外網絡的 SNAT 階段。在節點上添加 iptables 規則,同時在 Server 端添加路由,實現 Pod 對外直接暴露的效果,使 Pod → Server 的流量繞過 SNAT。再次測試,問題未復現。

9、在集羣中另選一個節點(node2),通過添加 iptables 規則和路由的方式,實現 node2 訪問 Server 也是通過 node1 做 SNAT 轉換的方式,測試 node2 訪問 Server,未出現問題。

10、排查 tcp、conntrack 相關的 sysctl 參數,未發現異常。

11、排查資料

https://knowledge.broadcom.com/external/article/293896/tcp-resets-sent-by-ip-conntrack-for-cont.html和

kube-proxy Subtleties: Debugging an Intermittent Connection Reset | Kubernetes

文章給出的解決方法是解決方法為 echo 1 > /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal。

雲計算-pod下載外節點大文件時中斷-connection reset by peer_TCP_05

雲計算-pod下載外節點大文件時中斷-connection reset by peer_Server_06

經測試,方法有效。

要永久設置 nf_conntrack_tcp_be_liberal 參數,你可以在 /etc/sysctl.conf 文件中添加一行 net.netfilter.nf_conntrack_tcp_be_liberal=1。然後,運行 sysctl -p 命令來應用更改。這樣,在每次系統啓動時,這個參數都會被設置為 1。

參數解釋

nf_conntrack_tcp_be_liberal 是 Linux 內核中與 netfilter 連接跟蹤(conntrack) 相關的一個重要參數,主要用於控制 TCP 連接在遇到 非標準或異常 TCP 包 時的行為。

默認值:0

作用:

當設置為 0(嚴格模式):內核會嚴格按照 RFC 標準校驗 TCP 包的狀態(如序列號、窗口、標誌位等)。如果收到“不合規範”的包(例如亂序、重傳、SYN 重疊等),連接跟蹤模塊可能認為該連接已損壞,從而 丟棄包或提前終止 conntrack 條目。

當設置為 1(寬鬆模式):內核對 TCP 協議的校驗更寬容,即使收到一些“不規範”但實際可接受的包(常見於高延遲、NAT 網絡、負載均衡器後),也不會輕易丟棄連接。這能 減少因 conntrack 誤判導致的連接中斷

容器環境下,不開啓這個參數可能造成 NAT 過的 TCP 連接帶寬上不去或經常斷連。

現象是有一點時延的 TCP 單流速度慢或經常斷連,比如:

  1. 跨地域專線掛載 nfs ,時延 5ms,下載速度就上不去,只能到 12Mbps 左右。
  2. 經過公網上傳文件經常失敗。

原因是如果流量存在一定時延時,有些包就可能 out of window 了,netfilter 會將 out of window 的包置為 INVALID,如果是 INVALID 狀態的包,netfilter 不會對其做 IP 和端口的 NAT 轉換,這樣協議棧再去根據 ip + 端口去找這個包的連接時,就會找不到,這個時候就會回覆一個 RST,但這個 RST 是直接宿主機發出,容器內不知道,導致容器內還以為連接沒斷不停重試。 所以如果數據包對應的 TCP 連接做過 NAT,在 conntrack 記錄了地址轉換信息,也有可能部分包因 out of window 不走 conntrack 轉換地址,造成一些混亂導致流量速度慢或卡住的現象。