作者： Colin Jao 饒康立 – VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化暨分散式安全防護技術方案的介紹與推廣。

這篇網誌裡我們要和大家展示在NSX-T內的troubleshooting工具，並利用前幾篇網誌演示時使用的K8S整合環境繼續給大家看NSX-T的除錯威力。一般來說，當網路工程師需要進行網路的troubleshooting時，我們想要做幾件事情：

  • 我們可不可以看到機器間是怎麼連接的？
  • 我們能不能在機器間，一個點一個點去確認哪個地方出錯連接失敗？
  • 我們可不可以直接收一台機器或一堆機器的網路封包來分析？
  • 我們可不可以把一台機器或一堆機器的網路流統計資訊收集起來做後續統計？

在NSX-T內，這些需求『全部都有考慮到』。我們可以用Port Connection / Traceflow / Port Mirror Session / IPFIX等等功能來進行。延續之前網誌內的展示，我們把目前使用的application內的所有Pods，以及在K8S預設環境所建立的Pods都顯示如下，而其中將後續展示內會使用到的Pod特別標注出來

其中yelb-ui這個微服務是做前端網頁的UI，yelb-appserver是作投票的邏輯運算。而下面的nginx則是在這個展示內建立的南北向load-balancer容器。此外，這些Pod所在的K8S節點 (k8s-node2 / k8s-node1) 在底層也都位於不同的vSphere上。

在NSX-T內，Port Connection可以快速地檢視各個虛機或是Pod (logical port) 間的連接關係以及目前的狀態。而Traceflow更進一步，除了Port Connection本身已經顯示的資料外，會以實際的封包測試兩個構件間各個接點是否運作正常。我們直接用Traceflow來進行k8s-cl1-yelb-ui-127081435-1tvt4與k8s-cl1-yelb-appserver-3315541501-s2vmj這兩個Pod間的連線檢測：

結果內，左邊顯示的是構件間的邏輯與實體網路拓墣。在上面的邏輯圖內，因為這兩個Pod都是在同一個應用內，在NSX-T環境內是接到同一個邏輯交換器，因此就顯示出兩個構件直接接在同一個交換器內。左邊下面是實體的vSphere設備資訊，我們可以把綠色的tunnel點開，顯示出目前這兩台vSphere之間邏輯網路是採用GENEVE協定，狀態正常，以及對應的TEP介面資訊

右邊則是Traceflow一步一步的過程，可以看到這兩個Pod間的通訊由來源端微分段防火牆，送到底層的TEP介面，由ESX-NSXT-3-TN轉送到ESX-NSXT-4-TN，又通過防火牆後到達目的容器。每段流程內節點都可以點擊看進一步資訊，比如說防火牆規則是因為哪一條允許通過之類的。

上面的圖看來很簡單，我們來看另一個Pod k8s-cl1-yelb-ui-127081435-90xvv與Load Balancer (nginx-ingress-rc-nq4zm) 間怎麼連接的

這個圖就複雜多了。大家可以看到因為來源與目的地完全在不同的網段（這邊的網段是由/27切開），NSX-T上這兩個Pod也位於不同的邏輯交換器，因此邏輯架構內是通過了不同的路由器（中間的藍色部分）才互通。邏輯圖內就好像大家用實體設備互接的感覺，兩個終端設備（藍色像雲的部分）各自接到交換器，交換器又接到中間的路由器，而且每個介面都直接列出，也可以點擊確認對應的名稱。而下面與右邊則與前張圖類似，包含實體設備上怎麼連接，還有邏輯網路內一個一個節點的路徑到底為何。

好，接著我們來看下個工具Port Mirror。NSX-T內同時支援本地以及遠端的Port Mirror，以前如果需要實體環境內做封包分析很複雜的，網路Team得要在線路上接個實體的tap或是在交換器上對於某個port / vlan啟用SPAN功能，而如果是虛擬環境就更麻煩了。但在NSX-T內我們可以這樣做。如果要做Remote Port Mirror，首先我們設定一個Profile，定義要送往的IP地址

然後到要啟用封包收集的虛機或是Pod上面，把剛剛所設定的Port Mirror Profile給設定上去。下圖內，我們要求將k8s-cl1-yelb-ui-127081435-1tvt4這個Pod的進出封包都送到10.66.0.103去，此時相關的封包就都會複製一份，然後透過GRE tunnel送往10.66.0.103。

接下來我們在10.66.0.103這台機器上開Wireshark，而且選擇ip proto 47 (GRE)。做一些測試。首先我們透過 # kubectl exec指令，從k8s-cl1-yelb-ui-127081435-1tvt4以ping指令連往8.8.8.8

Wireshark內很明確地抓到了這些ping封包，帥耶老皮

接著我們把實際的應用打開。大家看到的這個畫面是VMworld 2017 Keynote內有展示的一個簡單應用，以微服務的方式撰寫，可以用來投票哪個餐廳比較好。用瀏覽器連到這個網頁，隨便投一下票：

Wireshark內，我們可以看到由10.4.0.2 (load balancer) 連往10.4.0.132 (k8s-cl1-yelb-ui-127081435-1tvt4) ，然後這個負責UI的Pod又利用4567 Port往後連到10.4.0.137 (k8s-cl1-yelb-appserver-3315541501-m12hf) 這個負責投票運算的Pod上

上面我們和大家示範了NSX-T內traceflow / port mirror的功能，相信大家和我一樣會覺得有了這些工具，後續在虛機與K8S環境內要做troubleshooting真是一塊小蛋糕吧！剩下一個IPFIX的功能，因為這在以前vDS / NSX for vSphere都有支援，而後端vRNI這邊之前我們也和大家都介紹過，就省略了，相信大家都會認為這功能肯定OK的吧（爽朗）

後面網誌是本系列談NSX-T與K8S整合的最後一篇。我們要回顧一下前幾篇談的概念，最後整理出在SaaS App生產環境內，運用NSX-T 搭配K8S的必要性。