問(wèn)題背景
為了解決節(jié)點(diǎn)上請(qǐng)求部分service延遲63s問(wèn)題[1]，我們臨時(shí)把OS的版本換成了Redhat 8.4（內(nèi)核版本4.18.0-305），在VMware上虛出3節(jié)點(diǎn)集群后部署跨三層環(huán)境失敗，提示Harbor部署失敗。
原因分析
說(shuō)明：距離定位這個(gè)問(wèn)題已經(jīng)有一段時(shí)間了，其實(shí)最終也沒(méi)完全定位出根本原因，所以當(dāng)時(shí)也沒(méi)有整理記錄定位過(guò)程，這里就簡(jiǎn)單描述一下，做個(gè)記錄。
通過(guò)查看Harbor的日志，發(fā)現(xiàn)部署失敗的原因是健康檢查失敗，因?yàn)镠arbor的podIp:port請(qǐng)求在跨三層下超時(shí)，抓包發(fā)現(xiàn)請(qǐng)求經(jīng)過(guò)vxlan.calico時(shí)止于SYN_SENT報(bào)文；
實(shí)測(cè)發(fā)現(xiàn)，該環(huán)境上不僅是Harbor的podIp:port請(qǐng)求超時(shí)，其他pod服務(wù)的請(qǐng)求經(jīng)過(guò)跨三層的網(wǎng)絡(luò)也同樣存在問(wèn)題，說(shuō)明是一個(gè)共性問(wèn)題，并且pod網(wǎng)段的七層如http請(qǐng)求受影響，4層的icmp請(qǐng)求不受影響）；
繼續(xù)通過(guò)抓包確認(rèn)，podIp:port的請(qǐng)求已經(jīng)發(fā)送到節(jié)點(diǎn)網(wǎng)卡上，但跨三層對(duì)端的節(jié)點(diǎn)沒(méi)有收到。所以，可以排除主機(jī)上的iptables和路由的影響。實(shí)際上，也確實(shí)跟蹤了iptables的請(qǐng)求過(guò)程，確認(rèn)請(qǐng)求沒(méi)有被丟棄；
綜上，初步懷疑請(qǐng)求被跨三層網(wǎng)絡(luò)的中間設(shè)備（如交換機(jī)、路由器）丟棄了，之后相關(guān)同事在交換機(jī)上抓包，發(fā)現(xiàn)ping包可以抓到，但http請(qǐng)求依然抓不到，說(shuō)明交換機(jī)側(cè)也沒(méi)有收到報(bào)文，問(wèn)題原因進(jìn)一步縮小，可能情況有：
通過(guò)ehtool -s xxx命令統(tǒng)計(jì)虛機(jī)網(wǎng)卡報(bào)文信息，沒(méi)有發(fā)現(xiàn)丟棄情況，說(shuō)明問(wèn)題不在虛機(jī)的出網(wǎng)卡；
關(guān)于VMware丟棄報(bào)文的情況，找到一些資料[2-6]，比如混雜模式，mms配置都會(huì)有影響：
1) 通過(guò)ping命令指定報(bào)文長(zhǎng)度，發(fā)現(xiàn)跨網(wǎng)段依次ping一下pod的ip均返回正常，確認(rèn)不是mms問(wèn)題; ping -s 1000 177.177.x.x ping -s 1472 177.177.x.x ping -s 1500 177.177.x.x 2) 通過(guò)臨時(shí)修改網(wǎng)卡為混雜模式，測(cè)試問(wèn)題依然存在;
進(jìn)一步在服務(wù)器物理網(wǎng)卡上抓包（登錄esxi后臺(tái)，使用pktcap-uw –uplink vmnicX –dir 2 -o result.pcap，其中vmnicX表示虛機(jī)關(guān)聯(lián)的上行口物理網(wǎng)卡, dir 2表示同時(shí)抓取雙向請(qǐng)求）, 依然是ping包可以抓到，但http請(qǐng)求依然抓不到，說(shuō)明服務(wù)器物理網(wǎng)卡上也沒(méi)有收到報(bào)文；
最后，丟包范圍縮小到VMare下的虛機(jī)機(jī)請(qǐng)求出網(wǎng)卡后，到服務(wù)器物理網(wǎng)卡前 ，這中間涉及到虛擬化的實(shí)現(xiàn)，具體還有什么處理就不清楚了，最后改為使用物理服務(wù)器部署；
解決方案
臨時(shí)改用物理服務(wù)器部署跨三層集群成功，如果要使用VMware虛機(jī)部署，還需要繼續(xù)排查根因。
