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

前篇網誌我們簡介了NSX Application Platform (NAPP) 這個NSX 3.2版內的新構件、上面運作的服務、以及架構設計上改採用Kubernetes搭配微服務方案。如果客戶環境要運作 NSX Intelligence / NDR / Malware Prevention / Metrics等等新功能,必須先建立NSX Application Platform平台。要搭建這個平台,請先準備好Kubernetes環境。簡而言之,現在:

請各位把自己當作一名Kubernetes管理者,不僅僅是 vCenter管理者。

因此,NSX Application Platform的安裝相關準備與考量點,其實相當於開發team有一個新應用要裝到現有的K8S環境。以一個Kubernetes管理者的身份,應用上線前至少該考量與準備的包含了下列這些需求:

  • Kubernetes需要第幾版,是否有特別發行版要求?
  • 計算需求為何,CPU/Memory需求是多少。
  • Storage上的容量要求是什麼,會不會得動態擴張。
  • 應用遞送上的要求是什麼,是否需要 Load Balancer Service / Ingress服務。
  • 是否需要特定的網路功能,是否限制採用那種CNI (Container Network Interface)?
  • 服務要使用哪些對外IP?DNS內要註冊哪些IP與名稱對應?
  • 應用部署進來的機制是什麼?放在外部的Repository還是企業內的私有環境?

相關NAPP的安裝前需求準備請參考下面兩份正式文件:

  • NSX Application Platform Deployment Prerequisites
    ( https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/nsx-application-platform/GUID-D54C1B87-8EF3-45B3-AB27-EFE90A154DD3.html )
  • NSX Application Platform System Requirements
    ( https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/nsx-application-platform/GUID-85CD2728-8081-45CE-9A4A-D72F49779D6A.html )

但在這邊,我想直接就上面提出的各項問題,就NSX Application Platform此應用在安裝時的相關要求很快進行討論:

NAPP部署時Kubernetes需要第幾版,是否有特別發行版要求?

與文件內說明略為不同,請大家不用考慮Kubernetes 1.18之前版本,直接用1.19~1.21版本。本文寫作時,最新的K8S 1.22版尚未支援。

其次,後續應該還會增加,但目前支持的發行版只有兩種:

  • 主流的原生K8S發布版
  • 基於 vSphere with Tanzu 或是 Tanzu Kubernetes Grid的K8S叢集 (Tanzu Kubernetes Cluster)

也就是說在目前時間點 (NSX-T 3.2),其他友商的發行版或公有雲的原生部署尚未支持。現行初步僅支持在原生K8S或是Tanzu環境內。

NAPP的計算需求為何,CPU/Memory需求是多少?

雖然大家看NAPP文件裡面有不同部署配置,但說實話,要跑完整功能且在生產環境,終究是必須要走到最大型配置 (Advanced) 版本的。在此配置內,

  • 需要至少三個以上worker nodes。若資源足夠,建議另外配置1~2個額外的worker nodes
  • 每個worker nodes最低需要 16 vCPU,64GB Memory
  • 叢集內Control Nodes 不需要那麼大,生產環境內建議就是至少2 vCPU,4GB以上 Memory,建議有多台互為備援

NAPPStorage上的容量要求是什麼,會不會得動態擴張。

每一個worker node應該要能對應到1T的外部Storage空間。此『外部』Storage空間應該可以讓各個node共用,且可在需要時動態增加,比如說透過VMware CSI機制呼叫VMware vSAN來提供共用的外部儲存

NAPP於應用遞送上的要求是什麼,是否需要 Load Balancer Service / Ingress服務。

NAPP部署時需要Kubernetes叢集內提供 L4 Load Balancer Service, L7 Ingress則不需要。

NAPP運作時是否需要特定的網路功能,得採用那種CNI (Container Network Interface)

不需要,NAPP支持各種主流CNI,Antrea / Calico / Flannel都沒問題,沒有特別在網路底層的特殊要求。

NAPP會使用多少個對外IPDNS內要註冊哪些IP與名稱對應?

NAPP需要至少5個可透過Load Balancer配置的對外IP地址。其中一個Service IP需要在DNS內註冊對應的FQDN

NAPP部署進來的機制是什麼?放在外部的Repository還是企業內的私有環境?

VMware有提供 public repository供NAPP所有構件之下載,但許多環境由於Internet連線的限制,亦可於環境內具備私有容器庫如Harbor來放置NAPP構件。同時,此私有容器庫應該要支持helm-chart的配置方式

以上,大家看到頭昏了嗎?要符合上述需求可以有不同配置方式,但在後續的介紹內,我會採用下列的方式提供建議:

  • 建立一組 4-node的vSAN-Ready Cluster,安裝vCenter / vSphere並啟用 vSAN
  • 當然,配置 NSX-T 3.2版
  • Kubernetes透過Tanzu Kubernetes Grid方式在vSphere上配置,Tanzu Kubernetes Cluster採用1.21版本的TKR
  • 以vSAN提供需求的外部儲存空間
  • 使用NSX Advanced Load Balancer提供TKC內需求的Load Balancer服務,並透過NSX ALB的DNS服務自動進行Service註冊
  • Container Network Interface選用TKC預設的Antrea
  • Internet連線頻寬足夠的話推薦使用VMware公開的容器庫,但若需採用私有容器庫,則建立獨立的Harbor + Helm Chart

畫張圖,大概是下面這樣:

後面網誌我不會做細部的Step-by-Step配置說明,但會就這樣的環境建置的各個相關步驟,重點性地與大家進行討論。