tcpdump抓包分析過程

本次抓包緣由：
公司統一採用阿里雲k8s和slb服務；node開發的kuaizimu在調用saas服務的時候，沒法調用到saas的api接口，發現超時問題嚴重。問到其餘團隊調用saas服務的同事（公司的zishuo項目組和dupa項目組），均表示能正常訪問saas服務，並沒有出現超時現象。
也就是說：saas服務一直可以穩健提供服務，網絡也沒有出問題。

排查了好久，開發和運維都咬定不是本身的問題；
開發說：我線下開發環境能夠訪問，到了線上就不行；無能爲力。並表示代碼從始至終爲獲取到saas的api接口數據
運維說：其餘人的服務是正常的，就只有你的代碼不能鏈接，確定是你代碼的問題，從新檢查。
saas開發團隊的同事提議：採用tcpdump抓包，看看中間的網絡鏈路到哪裏出了問題？運維同事表示贊同。因而開啓tcpdump抓包的歷程。

環境介紹：
公司統一採用阿里雲k8s和slb向外提供服務；node和saas的服務都部署在k8s集羣環境中。node端（kuaizimu-admin-gray.bhbapp.cn）訪問saas服務（vpc-saas-pay-gray.bhbapp.cn）超時
node的ip爲172.25.3.10
saas 的ip爲172.25.3.192
公網SLB的ip爲
內網SLB的ip爲10.19.3.186

具體拓撲圖以下：

在node項目中安裝tcpdump軟件，對其進行抓包；獲取到的數據以下：
安裝wireshark，對抓取到的數據進行分析：如圖

第一次抓包的時候發現node端在發起請求的時候有Retransmission從新發送的現象，懷疑是對端拒絕了這個請求。通過查證，對端的ip10.19.3.186爲SLB的地址。
saas以爲證據仍舊不夠，不太具有說服力，因而進行第二次抓包，一樣是在node端進行抓包分析。發現這種現象重複發生，而且只要node端發出請求都會有相同的包被拒絕；開始懷疑是node端請求在通過slb的時候被拒絕，而saas一直沒收到過node端請求。
抓包到這裏引起了兩個猜測：
一：是slb出了問題？仍是k8s不支持這種slb的解析方式？總之slb和k8s確定有一方出現問題。
二：爲何node端的域名解析會通過slb呢？按道理來講k8s自己就劇本解析能力不需通過k8s集羣外面的slb

爲了驗證猜測：開始了兩步工做：
一、 提交1個SLB工單，看看是否是阿里雲的slb出現問題，想查詢slb的訪問日誌
二、 提交1個k8s工單，看看有沒有更好的解析方式

果真，阿里雲工做人員回答說：k8s集羣內容器之間的服務調用，能夠直接走k8s集羣內網解析，不須要通過外部的slb。在容器內嘗試鏈接容器的servicename，方案可行。
這裏就多是node端鏈接的域名出現問題，詢問zishuo項目和dupa項目的同事，發現他們訪問的域名果真和node端不一致；分別爲公網域名和k8s內網域名。驗證了以前的猜測。

解決了問題，並解答出以前的訪問超時的緣由：
k8s集羣內容器之間的服務調用，域名統一使用 "項目名.命名空間.svc.cluster.local" ；這個僅在k8s集羣內解析。
外網之間調用k8s服務，直接使用公網的域名便可
注：
k8s集羣內的容器之間的服務調用 不能走ECS的vpc網絡，這種狀況集羣會把slb的ip當着是service的ip就進行轉發。

總結：
node端修改了鏈接地址以後，恢復正常訪問。建議：之後容器之間的調用地址直接使用k8s內網域名便可。