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

前篇網誌內我們用了一張示意圖顯示在NSX-T整合K8S時，Pod / Node / NSX-T / 底層的Hypervisor間的關聯，以及各個Pod如何透過邏輯網路的方式在不用NAT的狀況下相互連通。這篇網誌內，我們同樣把這張圖叫回來：

大家應該有發現，每個Pod除了將邏輯網路介面直接連往底層Hypervisor內的邏輯交換器外，Pod與邏輯交換器的接口前，也都受到了分散式防火牆 (Distributed Firewall) 的防護。也就是說，在這個架構下，我們一樣能夠實作微分段，每一個Pod都是一個獨立可進行防護的單元。

以前在進行NSX for vSphere內的微分段介紹時，我們有和大家談論過，微分段機制的兩個重點：

1. 無論是同網段或不同網段，我們能夠以最小虛機為單位，以集中管理的方式，做到虛機與虛機間的防護

2. 我們能夠建立安全群組，以列出條件的方式，將安全群組與要管理的目標進行對應，做到部門、業務、專案間的虛機阻隔，進一步做到安全自動化

上面的敘述，將虛機置換為K8S內的Pod一樣成立。我們能夠做到微服務與微服務間，甚至微服務內、Pod與Pod間的最細緻安全防護。而且同樣地，可以利用群組的機制來進行防火牆政策的設定。好，但問題來了，以前我們在NSX for vSphere的管理介面內建立安全群組時，可以用一個虛機的VM名稱、主機名稱、作業系統、或是在vCenter內是屬於哪個叢集哪個Port Group哪個Resource Pool這些來進行分類，但Pod不是虛機啊？

相信您已經知道了。其實在生產環境內，我們最常用來作微分段分類條件的是安全標籤。K8S的整合內，同樣有這個機制。當應用Team要部署微服務時，可以直接利用Label的方式來進行Pod的註記。延續前篇網誌的展示，下圖內，是我們在部署展示環境時，yelb-app這個應用的Deployment宣告檔，裡面針對yelb-ui這個微服務的部署，特別加上了三個標籤如下

以這個宣告檔部署出的Pod，都會被加上上述app: yelb-ui / tier: frontend / secgroup: yelb-web-tier的標記。下面，我們選擇yelb-ui-127081435-1yvy4這個pod，並且觀察其對應的描述檔，如接下來兩張圖所示：

在這個Pod的描述內可以看到，剛剛我們打的三個標籤 app: yelb-ui / tier: frontend / secgroup: yelb-web-tier，都有在這個Pod上生效。

此時，我們在NSX上，就可以用這些標籤來建立群組的定義了。NSX-T內我們可以建立NSGroup（對應到以前NSX for vSphere的Security Group）。下圖內，我們建立了一個群組叫yelb-Frontend，設定了兩個條件：有一個對應到app scope的標籤叫yelb-ui，而且還有一個對應到secgroup的標籤叫yelb-web-tier（這邊僅為舉例，要用一個或多個條件均可）

然後我們可以看到，在yelb-ui裡面的各個Pod都被包含在這個群組內了

我們可以一路下去把不同的微服務、不同的應用都各自將安全群組定義出來。但這邊的概念相信大家都熟悉，就不重複了。這裡我們來做個驗證：首先，透過 # kubectl scale指令，把這個微服務由目前的三個Pod改為五個

馬上下圖內可以看到，這些新增的Pod也在安全群組內冒出來了。

接著用ping的方式來做個驗證。如同前篇網誌，我們用# kubectl exec指令，由yelb-ui-127081435-1yvy4這個pod去連在同一個k8s-node1上的另一個pod: 10.4.0.133。大家可以看到原本是連通的，但為什麼過了幾秒後，突然變成了Destination Unreachable呢？

因為在做這個ping的動作時，我們到NSX的介面上，將來源是yelb-Frontend、目的地也是yelb-Frontend的網路流，由原本的允許改為拒絕了，如下所示。

在這個演示內，我們向大家展示了即使是位在同一個node上的不同容器，我們能夠很輕易地用NSX像之前管理虛機一般，來進行必要的防護與阻隔。同樣地，我們能夠在K8S+NSX-T的環境內，透過建立安全群組的方式，自動地將要防護的應用或微服務進行分類，達成安全自動化。

如果企業建立一個私有雲內的Kubernetes環境，而安全部分的相關管理是由獨立的資安團隊負責，那上面利用Label / Group的方式就是我們推薦的管理機制：資安團隊負責進行安全群組的設計及群組間安全政策的配置，應用團隊在產出虛機 / 容器時以打標籤的方式進行標記，讓容器產出時自動加入對應的群組。但在另一方面，Kubernetes的較新版本內也支援另一種機制叫Network Policy，這是可以讓開發團隊自己以YAML檔形式，自行在應用部署時來宣告防火牆規則。Network Policy的機制在NSX內也是支援的。

以上是我們對於NSX-T搭配K8S的微分段機制簡述與展示。下一篇，我們要演示另一個NSX-T的領先技術：K8S環境內邏輯網路環境的Troubleshooting。