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

前兩篇網誌我和大家說明了要使用NSX-T 3.2版後的Metrics / Intelligence / NDR / Malware Prevention等新功能，必須要先建置NSX Application Platform構件。而此構件由於設計上考慮要開放、易於擴充、部署至不同平台等考量，會需要建置在Kubernetes環境內。因此，同時也和大家說明了需求的Kubernetes版本、計算與儲存、網路、容器庫等相關需求。環境可以用不同方式建置，但我會以基於Tanzu Kubernetes Grid 1.5.1版，運作於vSphere / vSAN上的方式與大家進行說明。

開始真正進行安裝前，必須先討論的是個沈悶但需要確認的項目：要把NSX Application Platform建立起來，運作於生產環境或進行測試，此時底層的設備以及網路配置有什麼需求，得要預先準備？

底層設備需求

如前篇所述，NAPP在計算與儲存資源的需求量相當大，生產環境要求至少3個Kubernetes Worker Node，每個Node要16 vCPU / 64 GB Memory以上，以及1TB對應的外部儲存空間。要達成這樣的需求，我建議是有一組獨立的vSphere Management Cluster可放置上述的Kubernetes Cluster，硬體相當於

  • 四台以上的實體伺服器，每台伺服器可提供 32 core CPU / 256 GB Memory以上的運算資源。
  • 伺服器需為vSAN Ready node，並提供至少5T以上的vSAN可用空間。
  • 每台伺服器有4個以上10 GB網路埠，可將vSphere平台管理與虛機Traffic分開運作。
  • 高速網路交換器把上面的網路埠連在一起，並提供需求的 vlan / routing等功能。

想必大家有一個問題：本來NAPP在Kubernetes要求的資源就很多了，為什麼上面我還加碼弄了更大的實體配置呢？是這樣子，通常我們和大家進行vSphere / NSX / vRealize等部署架構討論時，都會建議中大型環境內要有一組vSphere Management Cluster，可以放置包括vCenter / vRealize各方案構件 / NSX Manager / NSX ALB Controller等等管理構件。NAPP的屬性與上述構件是相同的。因此當我們用四台以上的vSphere建立起一組管理叢集，上面的資源不僅由NAPP使用還可以放置所有方案內管理構件。同時底層的vSAN儲存也可以提供管理構件及NAPP本身需求的外接儲存容量。

實體網路需求

首先大家必定很熟悉要安裝vSphere本身的底層網路需求如下，常見的配置方式包含了：

  • 管理網路：需要獨立vlan及網段，閘道配置，需要對Internet連線（可以用Proxy）。除了各個vCenter / vSphere / NSX / NSX ALB等等管理構件外，我們也會把配置Tanzu Kubernetes Grid需求的bastion host放在這個網段內
  • vMotion網路：獨立vlan及網段，不需要閘道
  • Storage / vSAN網路：獨立vlan及網段，不需要閘道

再來，我們應該要把NSX-T裝起來吧，不然NAPP要監控或安全保護什麼呢？因此可能會需要

  • NSX Overlay TEP網路：獨立vlan及網段，不需要閘道
  • NSX Uplink網路：獨立vlan及網段，這個網段要能夠連接到企業的實體路由器進行路由交換與南北向封包傳輸
  • 業務vlan網路：可能不是每個業務都放在overlay內而是放在實體網段，此時對應的實體業務網路當然需要在底層進行配置。

最後當我們要建立 Tanzu Kubernetes Grid及負載平衡器（這邊使用 NSX ALB及AKO構件），需要額外兩個網段：

  • Workload網路：放置TKG的管理叢集以及我們真正要使用的TKC叢集。這個網路需要獨立vlan及網段，閘道配置，需要對Internet連線（可以用Proxy）。在此網段內需要有DHCP服務，因為TKG目前在部署叢集時，各個K8S node需要透過DHCP取得IP地址
  • VIP網路：負載平衡器於此提供外部用戶連線到NAPP及K8S其他業務服務的外部IP網段。需要獨立vlan及網段，閘道配置，要不要有Internet連線就看應用用戶是來自哪邊了

進行網路配置討論時，客戶與經銷夥伴時常會詢問上面是不是真的一定要這麼多個實體網段 / vlan，可不可以少一點、合併在一起。可以，但是規劃上要想得非常清楚，在不同使用的範圍能夠清晰分開沒有任何overlap（DHCP範圍啦，不同的IP Pool配置使用範圍啦，管理構件指定IP範圍啦～～像這些的）。

其他Infrastructure需求

需要NTP就不用多說了，DNS也一樣。多說一句，此架構內我們採用NSX ALB搭配AKO，可以對NAPP的服務名稱 (Service Name) 對應FQDN在NSX ALB DNS內自動回應。此時，上層DNS需要能將指定K8S服務的網域進行委派 (delegation)。

好，東西準備好網路配好，接下來大家應該就要進行 vCenter / vSphere / vSAN / NSX-T / NSX ALB的基本安裝。這邊的相關步驟相信各位很熟悉，一些產品的配置流程如NSX-T / NSX ALB等在前面系列文也都有提到，我就不多談，若需要相關協助歡迎找VMware或聯絡我們的代理商與經銷商。接下來的網誌，假設底層的虛擬化環境、vSAN、NSX / ALB相關構件都安裝完成了，我們直接開始討論怎麼建立 NAPP 需求的 Tanzu Kubernetes Cluster。