接續前面的文章，對於在利用Kubernetes（K8S）的大型生產環境內，NSX-T如何提供網路接取及維運除錯的功能的展示，這裡將要與大家討論在Kubernetes環境內如何利用NSX-T做到Container間的微分段。
實作微分段
延續前篇文章的展示，圖2內，是在部署展示環境時yelb-app這個應用的Deployment宣告檔，裡面針對yelb-ui微服務的部署，特別加上三個標籤。
 |
| ▲ 圖2 針對yelb-ui微服務部署，加上三個標籤。 |
以這個宣告檔部署的Pod，都會被加上上述app: yelb-ui、tier: frontend、secgroup: yelb-web-tier的標記。接著，選擇yelb-ui-127081435-1yvy4這個Pod，並且觀察其對應的描述檔，如圖3～4所示。在這個Pod的描述內可以看到，剛剛設定的三個標籤app: yelb-ui、tier: frontend、secgroup: yelb-web-tier，都有在這個Pod上生效。
 |
| ▲ 圖3 選擇yelb-ui-127081435-1yvy4這個pod。 |
 |
| ▲ 圖4 觀察相對應的描述檔。 |
此時，在NSX上就可以用這些標籤來建立群組的定義。NSX-T內，可以建立NSGroup（對應到以前NSX for vSphere的Security Group）。圖5內建立了一個群組叫yelb-Frontend，設定了兩個條件：有一個對應到app scope的標籤叫yelb-ui，而且還有一個對應到secgroup的標籤叫yelb-web-tier。這邊僅為舉例，要用一個或多個條件均可。然後，如圖6所示可以看到，在yelb-ui裡面的各個Pod都被包含在這個群組內。
 |
| ▲ 圖5 建立yelb-Frontend群組並設定條件。 |
 |
| ▲ 圖6 在yelb-ui裡面的各個Pod都被包含在群組。 |
其實可以一路下去把不同的微服務、不同的應用都各自將安全群組定義出來。但這邊的概念相信大家都熟悉，就不重複了。就來做一個驗證，如圖7所示，首先透過「# kubectl scale」指令，把這個微服務由目前的三個Pod改為五個。
 |
| ▲ 圖7 把微服務改成五個Pod。 |
馬上，圖8內便會發現，這些新增的Pod也在安全群組內冒出來了。
 |
| ▲ 圖8 新增的Pod也在安全群組內出現了。 |
接著，用ping的方式來做個驗證。使用「# kubectl exec」指令，由yelb-ui-127081435-1yvy4這個Pod去連在同一個k8s-node1上的另一個Pod: 10.4.0.133。如圖9所示，大家可以看到原本是連通的，但為什麼過了幾秒後，突然變成了Destination Unreachable呢？
 |
| ▲ 圖9 執行ping指令進行驗證。 |
因為在做這個ping的動作時，到NSX的介面上，將來源是yelb-Frontend、目的地也是yelb-Frontend的網路流，由原本的允許改為拒絕（Reject），如圖10所示。
 |
| ▲ 圖10 將來源是yelb-Frontend、目的地也是yelb-Frontend的網路流改為Reject。 |
在這個演示中，即使位於同一個Node上的不同容器，也能夠很輕易地使用NSX像之前管理虛機一般來進行必要的防護與阻隔。同樣地，可以在K8S+NSX-T的環境內，透過建立安全群組的方式，自動地將要防護的應用或微服務進行分類，達成安全自動化。
如果企業建立一個私有雲內的Kubernetes環境，而安全部分的相關管理是由獨立的資安團隊負責，那上面利用Label/Group的方式就是這裡推薦的管理機制：資安團隊負責進行安全群組的設計及群組間安全政策的配置，應用團隊在產出虛機或容器時以打標籤的方式進行標記，讓容器產出時自動加入對應的群組。
但另一方面，Kubernetes的較新版本內也支援另一種機制叫Network Policy，這是可以讓開發團隊自己以YAML檔形式，自行在應用部署時來宣告防火牆規則。Network Policy的機制在NSX內也是支援的。
NSX-T+K8S在容器應用上的必要性
長篇大論了三篇文章，最後也要來個長篇大論的結論，討論NSX-T加上K8S在容器（Container）應用上的必要性。目前在和客戶進行討論時，常還會聽到一些疑問，像是為什麼一定要用容器？容器不是用在開發環境而已嗎？生產環境應該還是用虛機啊？而如果要部署容器的話，安裝Docker就好，為什麼要裝Kubernetes等等這些問題。
首先，以身為IT架構師與管理者的角色來說，要不要用Container架構其實不是Infrastructure Team能夠決定的。Container/CaaS等等架構的使用，是基於業務應用開發、維護、遞送形式的改變。
如同當應用從傳統的終端機模式改為Client/Server的時候，原本採用大型主機的系統就逐漸走向Open，變成Unix實體機或更進一步x86虛擬化的架構。而開發團隊要採用雲原生應用的架構編寫應用時，原本基於作業系統的虛機或實體機方式就太過臃腫與不易維護，採用Container是很自然的選擇。
這並不是說基於開放作業系統的實體機和虛機會消失，就如同現在許多銀行都還有在使用大型主機一般，虛機也仍然會持續存在很長的時間。但新的業務、新的應用會逐步開始以微服務的方式進行開發，趨勢是很明顯的。
想像一下，十年前當時大家對於生產環境內要用虛擬機仍有非常多的疑慮，但開發團隊在自己的電腦裝個VMware Workstation/Player是很常見的，一些應用開發就直接在自己桌機或筆電上的虛機進行。但當這些應用編譯測試完成，真的要上線時呢？