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社區。
【騰訊雲原生】雲說新品、雲研新術、雲游新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
