本次抓包原因：
公司統一採用阿里雲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、 提交1個SLB工單，看看是不是阿里雲的slb出現問題，想查詢slb的訪問日誌
2、 提交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內網域名即可。