容器網(wǎng)絡(luò)狀態(tài)異常排查記錄！

黃爸爸好 2020-08-18

展開(kāi)全文

文章來(lái)源：騰訊云原生

文章作者楊玉璽，2011年至今一直從事底層網(wǎng)絡(luò)研發(fā)，目前就職騰訊云 TKE 團(tuán)隊(duì)，專(zhuān)注 K8s 底層網(wǎng)絡(luò)。先后就職于阿里云、金山云從事 VPC 虛擬化網(wǎng)絡(luò)研發(fā)，對(duì)高性能網(wǎng)絡(luò)優(yōu)化，復(fù)雜網(wǎng)絡(luò)問(wèn)題排查有非常豐富的經(jīng)驗(yàn)。

導(dǎo)語(yǔ)

K8s容器網(wǎng)絡(luò)涉及諸多內(nèi)核子系統(tǒng)，IPVS，Iptable，3層路由，2層轉(zhuǎn)發(fā)，TCP/IP協(xié)議棧，這些復(fù)雜的內(nèi)核子系統(tǒng)在特定場(chǎng)景下可能會(huì)遇到設(shè)計(jì)者最初也想不到的問(wèn)題。

本文分享了iptable防火墻狀態(tài)異常導(dǎo)致丟包的排查記錄，這個(gè)排查過(guò)程非常曲折，最后使用了在現(xiàn)在的作者看來(lái)非常落伍的工具：systemtap，才得以排查成功。其實(shí)依作者現(xiàn)有的經(jīng)驗(yàn)，此問(wèn)題現(xiàn)在僅需一條命令即可找到原因，這條命令就是作者之前分享過(guò)文章使用 ebpf 深入分析容器網(wǎng)絡(luò) dup 包問(wèn)題中提到的skbtracker。時(shí)隔7個(gè)月，這個(gè)工具已經(jīng)非常強(qiáng)大，能解決日常網(wǎng)絡(luò)中的90%的網(wǎng)絡(luò)問(wèn)題。

此文其實(shí)已于2019年7月在騰訊內(nèi)部進(jìn)行發(fā)表，時(shí)隔一年，再次翻出來(lái)閱讀仍然有頗多收獲，因此把它分享出來(lái)給其他同行一起學(xué)習(xí)。此外，本篇文章也將作為開(kāi)篇，后續(xù)陸續(xù)分享作者近期使用ebpf工具排查各種內(nèi)核疑難雜癥的過(guò)程及經(jīng)驗(yàn)。

1. 問(wèn)題描述

騰訊內(nèi)部某業(yè)務(wù)在容器場(chǎng)景上遇到了一個(gè)比較詭異的網(wǎng)絡(luò)問(wèn)題，在容器內(nèi)使用GIT，SVN工具從內(nèi)部代碼倉(cāng)庫(kù)拉取代碼偶發(fā)性卡頓失敗，而在容器所在的Node節(jié)點(diǎn)使用同樣版本的GIT，SVN工具卻沒(méi)有問(wèn)題。用詭異這個(gè)詞，是因?yàn)檫@個(gè)問(wèn)題的分析持續(xù)時(shí)間比較久，經(jīng)歷了多個(gè)同學(xué)之手，最后都沒(méi)有揪出問(wèn)題根源。有挑戰(zhàn)的問(wèn)題排查對(duì)于本人來(lái)說(shuō)是相當(dāng)有吸引力的，于是在手頭沒(méi)有比較緊急任務(wù)的情況下，便開(kāi)始了有趣的debug。

從客戶(hù)描述看，問(wèn)題復(fù)現(xiàn)概率極大，在Pod里面拉取10次GIT倉(cāng)庫(kù)，必然有一次出現(xiàn)卡死，對(duì)于必現(xiàn)的問(wèn)題一般都不是問(wèn)題，找到復(fù)現(xiàn)方法就找到了解決方法。從客戶(hù)及其他同事反饋，卡死的時(shí)候，GIT Server不再繼續(xù)往Client端發(fā)送數(shù)據(jù)，并且沒(méi)有任何重傳。

1.1 網(wǎng)絡(luò)拓?fù)?/strong>

業(yè)務(wù)方采用的是TKE單網(wǎng)卡多IP容器網(wǎng)絡(luò)方案，node自身使用主網(wǎng)卡eth0，綁定一個(gè)ip，另一個(gè)彈性網(wǎng)卡eth1綁定多個(gè)ip地址，通過(guò)路由把這些地址與容器綁定，如圖1-1.

1.2 復(fù)現(xiàn)方法
1.3 抓包文件分析
在如下三個(gè)網(wǎng)口eth1，veth_a1，veth_b1分別循環(huán)抓包，Server端持續(xù)向Client發(fā)送大包，卡頓發(fā)生時(shí)，Server端停止往Client發(fā)送數(shù)據(jù)包，沒(méi)有任何重傳報(bào)文。

2. 排查過(guò)程
分析環(huán)境差異：Node和Pod環(huán)境差異
Node內(nèi)存比Pod多，而Node和Pod的TCP 接收緩存大小配置一致，此處差異可能導(dǎo)致內(nèi)存分配失敗。
數(shù)據(jù)包進(jìn)出Pod比Node多了一次路由判斷，多經(jīng)過(guò)兩個(gè)網(wǎng)絡(luò)設(shè)備：veth_a1和veth_b1，可能是veth的某種設(shè)備特性與TCP協(xié)議產(chǎn)生了沖突，或veth虛擬設(shè)備有bug，或veth設(shè)備上配置了限速規(guī)則導(dǎo)致。

分析抓包文件: 有如下特征
兩個(gè)方向的數(shù)據(jù)包，在eth1，veth_a1設(shè)備上都有被buffer的現(xiàn)象：到達(dá)設(shè)備一段時(shí)間后被集中發(fā)送到下一跳
在卡住的情況下，Server端和Client端都沒(méi)有重傳，eth1處抓到的包總比veth_a1多很多，veth_a1處抓到的包與veth_b1處抓到的包總是能保持一致

分析：TCP是可靠傳輸協(xié)議，如果中間因?yàn)槲粗颍ū热缦匏伲┌l(fā)生丟包，一定會(huì)重傳。因此卡死一定是發(fā)包端收到了某種控制信號(hào)，主動(dòng)停止了發(fā)包行為。

猜測(cè)一：wscal協(xié)商不一致，Server端收到的wscal比較小
在TCP握手協(xié)商階段，Server端收到Client端wscal值比實(shí)際值小。傳輸過(guò)程中，因?yàn)镃lient端接收buffer還有充裕，Client端累計(jì)一段時(shí)間沒(méi)及時(shí)回復(fù)ack報(bào)文，但實(shí)際上Server端認(rèn)為Client端窗口滿(mǎn)了（Server端通過(guò)比較小的wscal推斷Client端接收buffer滿(mǎn)了），Server端會(huì)直接停止報(bào)文發(fā)送。

如果Server端使用IPVS做接入層的時(shí)候，開(kāi)啟synproxy的情況下，確實(shí)會(huì)導(dǎo)致wscal協(xié)商不一致。

帶著這個(gè)猜想進(jìn)行了如下驗(yàn)證：
通過(guò)修改TCP 接收buffer（ipv4.tcp_rmem）大小，控制Client wscal值
通過(guò)修改Pod內(nèi)存配置，保證Node和Pod的在內(nèi)存配置上沒(méi)有差異
在Server端的IPVS節(jié)點(diǎn)抓包，確認(rèn)wscal協(xié)商結(jié)果
以上猜想經(jīng)過(guò)驗(yàn)證一一被否決。并且找到業(yè)務(wù)方同學(xué)確認(rèn)，雖然使用了IPVS模塊，但是并沒(méi)有開(kāi)啟synproxy功能，wscal協(xié)商不一致的猜想不成立。

猜測(cè)二：設(shè)備buffer了報(bào)文
設(shè)備開(kāi)啟了TSO，GSO特性，能極大提升數(shù)據(jù)包處理效率。猜測(cè)因?yàn)槿萜鲌?chǎng)景下，經(jīng)過(guò)了兩層設(shè)備，在每層設(shè)備都開(kāi)啟此特性，每層設(shè)備都buffer一段，再集中發(fā)送，導(dǎo)致數(shù)據(jù)包亂序或不能及時(shí)送到，TCP層流控算法判斷錯(cuò)誤導(dǎo)致報(bào)文停止發(fā)送。

帶著這個(gè)猜想進(jìn)行了如下驗(yàn)證：
1）關(guān)閉所有設(shè)備的高級(jí)功能（TSO，GSO，GRO，tx-nocache-copy，SG）
2）關(guān)閉容器內(nèi)部delay ack功能（net.ipv4.tcp_no_delay_ack），讓Client端積極回應(yīng)Server端的數(shù)據(jù)包
以上猜想也都驗(yàn)證失敗。

終極方法：使用systamp腳本揪出罪魁禍?zhǔn)?/strong>
驗(yàn)證了常規(guī)思路都行不通。但唯一肯定的是，問(wèn)題一定出在CVM內(nèi)部。注意到eth1抓到的包總是比veth_a1多那么幾個(gè)，之前猜想是被buffer了，但是buffer了總得發(fā)出來(lái)吧，可是持續(xù)保持抓包狀態(tài)，并沒(méi)有抓到這部分多余的包，那這部分包一定被丟了。這就非常好辦了，只要監(jiān)控這部分包的丟包點(diǎn)，問(wèn)題就清楚了。使用systemtap監(jiān)控skb的釋放點(diǎn)并打印backtrace，即可快速找到引起丟包的內(nèi)核函數(shù)。Systemtap腳本如圖2-1，2-2所示。
圖2-1 dropwatch腳本（不帶backtrce打?。?/section>
圖2-2 dropwatch腳本（帶backtrce打?。?/section>
首先通過(guò)圖2-1腳本找到丟包點(diǎn)的具體函數(shù)，然后找到丟包具體的地址（交叉運(yùn)行stap --all-modules dropwatch.stp -g和stap dropwatch.stp -g命令，結(jié)合/proc/kallsyms里面函數(shù)的具體地址），再把丟包地址作為判斷條件，精確打印丟包點(diǎn)的backtrace（圖2-2）。

運(yùn)行腳本stap --all-modules dropwatch.stp -g，開(kāi)始復(fù)現(xiàn)問(wèn)題，腳本打印如圖2-3：
圖2-3 丟包函數(shù)

正常不卡頓的時(shí)候是沒(méi)有nf_hook_slow的，當(dāng)出現(xiàn)卡頓的時(shí)候，nf_hook_slow出現(xiàn)在屏幕中，基本確定丟包點(diǎn)在這個(gè)函數(shù)里面。但是有很多路徑能到達(dá)這個(gè)函數(shù)，需要打印backtrace確定調(diào)用關(guān)系。再次運(yùn)行腳本：stap dropwatch.stp -g，確認(rèn)丟包地址列表，對(duì)比/proc/kallsyms符號(hào)表ffffffff8155c8b0 T nf_hook_slow，找到最接近0xffffffff8155c8b0 的那個(gè)值0xffffffff8155c9a3就是我們要的丟包點(diǎn)地址（具體內(nèi)核版本和運(yùn)行環(huán)境有差異）。加上丟包點(diǎn)的backtrace，再次復(fù)現(xiàn)問(wèn)題，屏幕出現(xiàn)圖2-4打印。
圖2-4 丟包點(diǎn)backtrace
圖2-5連接表狀態(tài)

可以看出ip_forward調(diào)用nf_hook_slow最終丟包。很明顯數(shù)據(jù)包被iptable上的FORWARD 鏈規(guī)則丟了。查看FORWARD鏈上的規(guī)則，確實(shí)有丟包邏輯(-j REJECT --reject-with icmp-port-unreachable)，并且丟包的時(shí)候一定會(huì)發(fā) icmp-port-unreachable類(lèi)型的控制報(bào)文。到此基本確定原因了。因?yàn)槭窃贜ode上產(chǎn)生的icmp回饋信息，所以在抓包的時(shí)候無(wú)法通過(guò)Client和Server的地址過(guò)濾出這種報(bào)文（源地址是Node eth0地址，目的地址是Server的地址）。同時(shí)運(yùn)行systamp腳本和tcpdump工具抓取icmp-port-unreachable報(bào)文，卡頓的時(shí)候兩者都有體現(xiàn)。

接下來(lái)分析為什么好端端的連接傳輸了一段數(shù)據(jù)，后續(xù)的數(shù)據(jù)被規(guī)則丟了。仔細(xì)查看iptalbe規(guī)則發(fā)現(xiàn)客戶(hù)配置的防火墻規(guī)則是依賴(lài)狀態(tài)的：-m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT。只有ESTABLISHED連接狀態(tài)的數(shù)據(jù)包才會(huì)被放行，如果在數(shù)據(jù)傳輸過(guò)程中，連接狀態(tài)發(fā)生變化，后續(xù)入方向的報(bào)文都會(huì)被丟棄，并返回端口不可達(dá)。通過(guò)conntrack工具監(jiān)測(cè)連接表狀態(tài)，發(fā)現(xiàn)出問(wèn)題時(shí)，對(duì)應(yīng)連接的狀態(tài)先變成了FIN_WAIT,最后變成了CLOSE_WAIT（圖2-5）。通過(guò)抓包確認(rèn)，GIT在下載數(shù)據(jù)的時(shí)候，會(huì)開(kāi)啟兩個(gè)TCP連接，有一個(gè)連接在過(guò)一段時(shí)間后，Server端會(huì)主動(dòng)發(fā)起fin包，而Client端因?yàn)檫€有數(shù)據(jù)等待傳輸，不會(huì)立即發(fā)送fin包，此后連接狀態(tài)就會(huì)很快發(fā)生如下切換：

ESTABLISHED(Server fin)->FIN_WAIT(Client ack)->CLOSE_WAIT
所以后續(xù)的包就過(guò)不了防火墻規(guī)則了（猜測(cè)GIT協(xié)議有一個(gè)控制通道，一個(gè)數(shù)據(jù)通道，數(shù)據(jù)通道依賴(lài)控制通道，控制通道狀態(tài)切換與防火墻規(guī)則沖突導(dǎo)致控制通道異常，數(shù)據(jù)通道也跟著異常。等有時(shí)間再研究下GIT數(shù)據(jù)傳輸相關(guān)協(xié)議）。這說(shuō)明iptables的有狀態(tài)的防火墻規(guī)則沒(méi)有處理好這種半關(guān)閉狀態(tài)的連接，只要一方（此場(chǎng)景的Server端）主動(dòng)CLOSE連接以后，后續(xù)的連接狀態(tài)都過(guò)不了規(guī)則（-m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT）。

明白其中原理以后，對(duì)應(yīng)的解決方案也比較容易想到。因?yàn)榭蛻?hù)是多租戶(hù)容器場(chǎng)景，只放開(kāi)了Pod主動(dòng)訪(fǎng)問(wèn)的部分服務(wù)地址，這些服務(wù)地址不能主動(dòng)連接Pod。了解到GIT以及SVN都是內(nèi)部服務(wù)，安全性可控，讓用戶(hù)把這些服務(wù)地址的入方向放行，這樣即使?fàn)顟B(tài)發(fā)生切換，因?yàn)闈M(mǎn)足入向放行規(guī)則，也能過(guò)防火墻規(guī)則。

3. 思考
在排查問(wèn)題的過(guò)程中，發(fā)現(xiàn)其實(shí)容器的網(wǎng)絡(luò)環(huán)境還有非常多值得優(yōu)化和改進(jìn)的地方的，比如：
TCP接受發(fā)送buffer的大小一般是在內(nèi)核啟動(dòng)的時(shí)候根據(jù)實(shí)際物理內(nèi)存計(jì)算的一個(gè)合理值，但是到了容器場(chǎng)景，直接繼承了Node上的默認(rèn)值，明顯是非常不合理的。其他系統(tǒng)資源配額也有類(lèi)似問(wèn)題。
網(wǎng)卡的TSO，GSO特性原本設(shè)計(jì)是為了優(yōu)化終端協(xié)議棧處理性能的，但是在容器網(wǎng)絡(luò)場(chǎng)景，Node的身份到底是屬于網(wǎng)關(guān)還是終端？屬于網(wǎng)關(guān)的話(huà)那做這個(gè)優(yōu)化有沒(méi)有其他副作用（數(shù)據(jù)包被多個(gè)設(shè)備buffer然后集中發(fā)出）。從Pod的角度看，Node在一定意義上屬于網(wǎng)關(guān)的身份，如何扮演好終端和網(wǎng)關(guān)雙重角色是一個(gè)比較有意思的問(wèn)題
Iptables相關(guān)問(wèn)題
此場(chǎng)景中的防火墻狀態(tài)問(wèn)題
規(guī)則多了以后iptables規(guī)則同步慢問(wèn)題
Service 負(fù)載均衡相關(guān)問(wèn)題（規(guī)則加載慢，調(diào)度算法單一，無(wú)健康檢查，無(wú)會(huì)話(huà)保持，CPS低問(wèn)題）
SNAT源端口沖突問(wèn)題，SNAT源端口耗盡問(wèn)題

IPVS相關(guān)問(wèn)題
統(tǒng)計(jì)timer在配置量過(guò)大時(shí)導(dǎo)致CPU軟中斷收包延時(shí)問(wèn)題

net.ipv4.vs.conn_reuse_mode導(dǎo)致的一系列問(wèn)題（參考：https://github.com/kubernetes/kubernetes/issues/81775 ）

截止到現(xiàn)在，以上大多數(shù)問(wèn)題已經(jīng)在TKE平臺(tái)得到解決，部分修復(fù)patch提到了內(nèi)核社區(qū)，相應(yīng)的解決方案也共享到了K8s社區(qū)。

本站是提供個(gè)人知識(shí)管理的網(wǎng)絡(luò)存儲(chǔ)空間，所有內(nèi)容均由用戶(hù)發(fā)布，不代表本站觀點(diǎn)。請(qǐng)注意甄別內(nèi)容中的聯(lián)系方式、誘導(dǎo)購(gòu)買(mǎi)等信息，謹(jǐn)防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請(qǐng)點(diǎn)擊一鍵舉報(bào)。

轉(zhuǎn)藏 分享

QQ空間 QQ好友新浪微博微信

獻(xiàn)花（0） +1

來(lái)自：黃爸爸好 > 《K 8》

舉報(bào)/認(rèn)領(lǐng)