0.導語
K8s容器網路涉及諸多核心子系統，IPVS，Iptable，3層路由，2層轉發，TCP/IP協議棧，這些複雜的核心子系統在特定場景下可能會遇到設計者最初也想不到的問題。
本文分享了iptable防火牆狀態異常導致丟包的排查記錄，這個排查過程非常曲折，最後使用了在現在的作者看來非常落伍的工具：systemtap，才得以排查成功。其實依作者現有的經驗，此問題現在僅需一條命令即可找到原因，這條命令就是作者之前分享過文章使用 ebpf 深入分析容器網路 dup 包問題中提到的skbtracker。時隔7個月，這個工具已經非常強大，能解決日常網路中的90%的網路問題。
此文其實已於2019年7月在騰訊內部進行發表，時隔一年，再次翻出來閱讀仍然有頗多收穫，因此把它分享出來給其他同行一起學習。此外，本篇文章也將作為開篇，後續陸續分享作者近期使用ebpf工具排查各種核心疑難雜症的過程及經驗。
1. 問題描述
騰訊內部某業務在容器場景上遇到了一個比較詭異的網路問題，在容器內使用GIT，SVN工具從內部程式碼倉庫拉取程式碼偶發性卡頓失敗，而在容器所在的Node節點使用同樣版本的GIT，SVN工具卻沒有問題。用詭異這個詞，是因為這個問題的分析持續時間比較久，經歷了多個同學之手，最後都沒有揪出問題根源。有挑戰的問題排查對於本人來說是相當有吸引力的，於是在手頭沒有比較緊急任務的情況下，便開始了有趣的debug。
從客戶描述看，問題復現概率極大，在Pod裡面拉取10次GIT倉庫，必然有一次出現卡死，對於必現的問題一般都不是問題，找到復現方法就找到了解決方法。從客戶及其他同事反饋，卡死的時候，GIT Server不再繼續往Client端傳送資料，並且沒有任何重傳。
1.1 網路拓撲
業務方採用的是TKE單網路卡多IP容器網路方案，node自身使用主網路卡eth0，繫結一個ip，另一個彈性網路卡eth1繫結多個ip地址，通過路由把這些地址與容器繫結，如圖1-1.
圖 1-1 TKE單網路卡多IP容器網路
1.2 復現方法
1.3 抓包檔案分析
在如下三個網口eth1，veth_a1，veth_b1分別迴圈抓包，Server端持續向Client傳送大包，卡頓發生時，Server端停止往Client傳送資料包，沒有任何重傳報文。
2. 排查過程
分析環境差異：node和Pod環境差異
- Node記憶體比Pod多，而Node和Pod的TCP 接收快取大小配置一致，此處差異可能導致記憶體分配失敗。
- 資料包進出Pod比Node多了一次路由判斷，多經過兩個網路裝置：veth_a1和veth_b1，可能是veth的某種裝置特性與TCP協議產生了衝突，或veth虛擬裝置有bug，或veth裝置上配置了限速規則導致。
分析抓包檔案: 有如下特徵
- 兩個方向的資料包，在eth1，veth_a1裝置上都有被buffer的現象：到達裝置一段時間後被集中傳送到下一跳
- 在卡住的情況下，Server端和Client端都沒有重傳，eth1處抓到的包總比veth_a1多很多，veth_a1處抓到的包與veth_b1處抓到的包總是能保持一致
分析：TCP是可靠傳輸協議，如果中間因為未知原因（比如限速）發生丟包，一定會重傳。因此卡死一定是發包端收到了某種控制訊號，主動停止了發包行為。
猜測一：wscal協商不一致，Server端收到的wscal比較小
在TCP握手協商階段，Server端收到Client端wscal值比實際值小。傳輸過程中，因為Client端接收buffer還有充裕，Client端累計一段時間沒及時回覆ack報文，但實際上Server端認為Client端視窗滿了（Server端通過比較小的wscal推斷Client端接收buffer滿了），Server端會直接停止報文傳送。
如果Server端使用IPVS做接入層的時候，開啟synproxy的情況下，確實會導致wscal協商不一致。
帶著這個猜想進行了如下驗證：
- 通過修改TCP 接收buffer（ipv4.tcp_rmem）大小，控制Client wscal值
- 通過修改Pod記憶體配置，保證Node和Pod的在記憶體配置上沒有差異
- 在Server端的IPVS節點抓包，確認wscal協商結果
以上猜想經過驗證一一被否決。並且找到業務方同學確認，雖然使用了IPVS模組，但是並沒有開啟synproxy功能，wscal協商不一致的猜想不成立。
猜測二：裝置buffer了報文
裝置開啟了TSO，GSO特性，能極大提升資料包處理效率。猜測因為容器場景下，經過了兩層裝置，在每層裝置都開啟此特性，每層裝置都buffer一段，再集中傳送，導致資料包亂序或不能及時送到，TCP層流控演算法判斷錯誤導致報文停止傳送。
帶著這個猜想進行了如下驗證：
1）關閉所有裝置的高階功能（TSO，GSO，GRO，tx-nocache-copy，SG）
2）關閉容器內部delay ack功能（net.ipv4.tcp_no_delay_ack），讓Client端積極回應Server端的資料包
以上猜想也都驗證失敗。
終極方法：使用systamp指令碼揪出罪魁禍首
驗證了常規思路都行不通。但唯一肯定的是，問題一定出在CVM內部。注意到eth1抓到的包總是比veth_a1多那麼幾個，之前猜想是被buffer了，但是buffer了總得發出來吧，可是持續保持抓包狀態，並沒有抓到這部分多餘的包，那這部分包一定被丟了。這就非常好辦了，只要監控這部分包的丟包點，問題就清楚了。使用systemtap監控skb的釋放點並列印backtrace，即可快速找到引起丟包的核心函式。Systemtap指令碼如圖2-1，2-2所示。
圖2-1 dropwatch指令碼（不帶backtrce列印）
圖2-2 dropwatch指令碼（帶backtrce列印）
首先通過圖2-1指令碼找到丟包點的具體函式，然後找到丟包具體的地址（交叉執行stap --all-modules dropwatch.stp -g和stap dropwatch.stp -g命令，結合/proc/kallsyms裡面函式的具體地址），再把丟包地址作為判斷條件，精確列印丟包點的backtrace（圖2-2）。
執行指令碼stap --all-modules dropwatch.stp -g，開始復現問題，指令碼列印如圖2-3：
圖2-3 丟包函式
正常不卡頓的時候是沒有nf_hook_slow的，當出現卡頓的時候，nf_hook_slow出現在螢幕中，基本確定丟包點在這個函式裡面。但是有很多路徑能到達這個函式，需要列印backtrace確定呼叫關係。再次執行指令碼：stap dropwatch.stp -g，確認丟包地址列表，對比/proc/kallsyms符號表ffffffff8155c8b0 T nf_hook_slow，找到最接近0xffffffff8155c8b0 的那個值0xffffffff8155c9a3就是我們要的丟包點地址（具體核心版本和執行環境有差異）。加上丟包點的backtrace，再次復現問題，螢幕出現圖2-4列印。
圖2-4 丟包點backtrace
圖2-5連線表狀態
可以看出ip_forward呼叫nf_hook_slow最終丟包。很明顯資料包被iptable上的FORWARD 鏈規則丟了。檢視FORWARD鏈上的規則，確實有丟包邏輯(-j REJECT --reject-with icmp-port-unreachable)，並且丟包的時候一定會發 icmp-port-unreachable型別的控制報文。到此基本確定原因了。因為是在Node上產生的icmp回饋資訊，所以在抓包的時候無法通過Client和Server的地址過濾出這種報文（源地址是Node eth0地址，目的地址是Server的地址）。同時執行systamp指令碼和tcpdump工具抓取icmp-port-unreachable報文，卡頓的時候兩者都有體現。
接下來分析為什麼好端端的連線傳輸了一段資料，後續的資料被規則丟了。仔細檢視iptalbe規則發現客戶配置的防火牆規則是依賴狀態的：-m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT。只有ESTABLISHED連線狀態的資料包才會被放行，如果在資料傳輸過程中，連線狀態發生變化，後續入方向的報文都會被丟棄，並返回埠不可達。通過conntrack工具監測連線表狀態，發現出問題時，對應連線的狀態先變成了FIN_WAIT,最後變成了CLOSE_WAIT（圖2-5）。通過抓包確認，GIT在下載資料的時候，會開啟兩個TCP連線，有一個連線在過一段時間後，Server端會主動發起fin包，而Client端因為還有資料等待傳輸，不會立即傳送fin包，此後連線狀態就會很快發生如下切換：
ESTABLISHED(Server fin)->FIN_WAIT(Client ack)->CLOSE_WAIT
所以後續的包就過不了防火牆規則了（猜測GIT協議有一個控制通道，一個資料通道，資料通道依賴控制通道，控制通道狀態切換與防火牆規則衝突導致控制通道異常，資料通道也跟著異常。等有時間再研究下GIT資料傳輸相關協議）。這說明iptables的有狀態的防火牆規則沒有處理好這種半關閉狀態的連線，只要一方（此場景的Server端）主動CLOSE連線以後，後續的連線狀態都過不了規則（-m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT）。
明白其中原理以後，對應的解決方案也比較容易想到。因為客戶是多租戶容器場景，只放開了Pod主動訪問的部分服務地址，這些服務地址不能主動連線Pod。瞭解到GIT以及SVN都是內部服務，安全性可控，讓使用者把這些服務地址的入方向放行，這樣即使狀態發生切換，因為滿足入向放行規則，也能過防火牆規則。
3. 思考
在排查問題的過程中，發現其實容器的網路環境還有非常多值得優化和改進的地方的，比如：
- TCP接受傳送buffer的大小一般是在核心啟動的時候根據實際實體記憶體計算的一個合理值，但是到了容器場景，直接繼承了Node上的預設值，明顯是非常不合理的。其他系統資源配額也有類似問題。
- 網路卡的TSO，GSO特性原本設計是為了優化終端協議棧處理效能的，但是在容器網路場景，Node的身份到底是屬於閘道器還是終端？屬於閘道器的話那做這個優化有沒有其他副作用（資料包被多個裝置buffer然後集中發出）。從Pod的角度看，Node在一定意義上屬於閘道器的身份，如何扮演好終端和閘道器雙重角色是一個比較有意思的問題
- Iptables相關問題
此場景中的防火牆狀態問題
規則多了以後iptables規則同步慢問題
Service 負載均衡相關問題（規則載入慢，排程演算法單一，無健康檢查，無會話保持，CPS低問題）
SNAT源埠衝突問題，SNAT源埠耗盡問題
- IPVS相關問題
統計timer在配置量過大時導致CPU軟中斷收包延時問題
net.ipv4.vs.conn_reuse_mode導致的一系列問題 （參考：https://github.com/kubernetes/kubernetes/issues/81775 ）
截止到現在，以上大多數問題已經在TKE平臺得到解決，部分修復patch提到了核心社群，相應的解決方案也共享到了K8s社群。
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！
