在生產環境橫跨數個實體設備的K8S環境中，若能夠結合VMware NSX-T一起運用，將可以讓多個Container順暢、自動且簡易地互相連通，而且還提供強大的工具來進行網路單位需求的除錯功能，本文先說明基本觀念，然後以實際操作來示範整個環境運作的情形。
3. 當管理者要部署一個應用或單一微服務時，K8S Master會依據各K8S Node虛機的負載，將Container包到Pod內，並且分散部署到不同的Node上。在圖2中總共有8個Pods，這些Pods分別被配置到不同的Node上，而且各自被設定一個特定的IP。
4. 當一個Pod建立時，NSX會將這個Pod的網路介面透過OVS，在內部以打vlan tag的方式接到底層Hypervisor的邏輯交換器上。在圖2內，8個Pods都可以透過底層的邏輯交換器二層互通。而在實體網路上，當然是透過標準的封裝機制（NSX-T內是採用Geneve）來進行實際的跨三層實體網路傳輸。
5. 無論用戶進行微服務內的Pod擴充（Scale-out）或移除，NSX-T會與K8S Master進行溝通，並將新增或移除的Pod介面在底層邏輯交換器上進行對應的增減。
接著，利用幾個實際的操作畫面進行說明。在圖3內可以發現目前展示的Kubernetes環境內有一個叫做yelb-app的Namespace。Namespace在K8S環境內的定義，代表一組給一群用戶開發專案的環境，這個環境內的名稱是獨一無二的，任何資源與物件在Namespace內不能重複。
 |
| ▲圖3 發現一個名為yelb-app的Namespace。 |
若在K8S內新增一個Namespace時，在NSX-T內會自動建立相對的Logical Switch以及Logical Router。從圖4～5中可以看到對應這個yelb-app Namespace的邏輯路由器及邏輯交換器。首先是邏輯路由器內，k8s-cl1-yelb-app路由器會在Namespace建立時自動產出。
 |
| ▲圖4 k8s-cl1-yelb-app路由器在Namespace建立時自動產出。 |
 |
| ▲ 圖5 k8s-cl1-yelb-app-0邏輯交換器在K8S管理者建立yelb-app namespace時由NSX-T自動產出。 |
接下來，用戶在這個Namespace內建立了他所需要的應用，圖6內，這個應用有三個微服務redis-server、yelb-appserver、yelb-ui，總共建立了7個Pods，各個Pods的IP地址以及位於哪一台K8S Node上均於圖6內顯示出來。
 |
| ▲ 圖6 三個微服務總共建立7個Pods。 |
而到NSX-T的介面內，可以看到在k8s-cl1-yelb-app-0這個交換器上，這些Pods都各自有一個對應的介面接取到此交換器，如圖7所示。
 |
| ▲ 圖7 每個Pods都各自有一個對應的介面接取到k8s-cl1-yelb-app-0交換器上。 |
這裡的配置是完全自動的，每當新增、刪除、擴充或更新Pod時，對應的邏輯網路介面就會建立並且接取到交換器上。把yelb-ui這個微服務內的Pods由原來的4個改為3個，但yelb-appserver的Pods則由2個變成3個。完成後，就會看到yelb-app這個應用內Pods的配置改變，如圖8所示。
 |
| ▲ 圖8 Pods的配置已經改變。 |
而在NSX內，如圖9所示，交換器上所接的邏輯網路介面也馬上自動改變。
 |
| ▲ 圖9 交換器上所接的邏輯網路介面馬上自動改變。 |
下面來做兩個驗證，以確認NSX邏輯網路運作正常。首先，嘗試連接在兩台不同K8s Node上的Pod（Container）。在圖10內，要求位於K8s-Node1這台虛機上的yelb-ui-127081415-1tvt4這個Pod，利用ping指令連往位於另一個Node（K8s-Node2）上而IP為10.4.0.134的Pod。即使這兩個Pod位於不同的Node，底層也在不同的vSphere Host上，透過邏輯網路，這兩個Pod可以互相連通。
 |
| ▲ 圖10 yelb-ui-127081415-1tvt4這個Pod利用ping指令連往位於另一個Node的Pod。 |
其次，直接用同樣的指令連往Internet，也是正常運作，如圖11所示。
 |
| ▲ 圖11 用同樣的指令連往Internet，也可正常運作。 |
進行至此，熟悉Kubernetes網路方案的讀者可能會覺得，用Flannel、Calico等等其他的方案也做得到跨K8S Node的網路連接啊！所以，接下來繼續展示NSX-T的除錯威力。