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