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社區，
【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/697.html
標籤：其他
上一篇：使用kind快速創建本地集群