server room electric 3d rendering
虛擬雲網路

網路虛擬化NSX 技術文章系列二百二十三: NSX Advanced Load Balancer容器方案支持(一):Kubernetes網路需求簡述

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

在之前的網誌內我們多次與各位介紹VMware技術領先的應用遞送方案:NSX Advanced Load Balancer (Avi Networks)。不同系列內,我們分別就方案本身架構、特性與效益,安裝流程及核心構件,分成多篇與大家討論。目前我們在台灣已經有多個包含政府、金融、製造、學校等不同客戶採用NSX Advanced Load Balancer作為本地負載平衡、網頁應用防火牆,甚至全域負載平衡等需求的部署方案,無論在功能、介面及穩定性上都備受用戶肯定。當然,一個方案做得好,使用的場景就會越來越擴大。我們最近就常被詢問一個問題:NSX Advanced Load Balancer可不可以運用在Kubernetes容器環境內呢?在客戶業務進行數位轉型的過程中,對於新建置基於容器的應用,運作在VMware Tanzu或原生K8S等不同Container as a Service平台內,對於LoadBalancer / Ingress等等需求,NSX Advancer Load Balancer有哪些特別的優勢呢?

當然可以的,而且我很直接地和大家拍胸脯,採用NSX Advancer Load Balancer在容器平台內,與一般開源方案或其他競爭友商的傳統應用遞送方案來說,是更適合、功能更全面、效益更完善的方案。

要這樣說大話當然得有所本。在接下來的系列文內,我想和大家介紹NSX Advancer Load Balancer內的容器支持架構機制:AKO (Avi Kubernetes Operator)。我們會逐一討論採用此方案的效益、架構、部署流程,並且針對此方案與競爭產品間的差異點進行說明,同時也會針對方案內會使用到的進階功能做討論。不僅是單純打廣告,希望系列文結束,大家能和我一樣,對於在容器環境內以Avi Kubernetes Operator方案提供應用遞送服務充滿信心。

但猜想在閱讀本文的各位讀者,可能並非都對Kubernetes平台的網路機制完全了解。因此作為系列文的第一篇,我想先跳脫產品,與大家簡述在K8S環境內的網路及安全構件,以及後續要與各位討論的主要功能範圍。下圖內,各位可看到在一個生產的Kubernetes環境內,一般來說可能會有三種主要的網路構件:

1. Container Network Interface

Container Network Interface又簡稱CNI,是K8S平台建立時的必要構件。Container Network Interface的最主要功能是用來提供Pod之間的網路連接以及需求的安全區隔。幾個主要的功能條列如下:

  • 提供Pod啟動時的IP地址,以及Pod與Pod之間不需要做NAT的直接網路連接。CNI需處理Pod之間連線時,底層如何跨越實體網路的封裝或路由機制。
  • 提供Pod間的連線安全控制,也就是在K8S內被稱為Network Policy的功能,大家可以想像這就是Pod之間的微分段。
  • 提供各個Pod到外部實體網路間的網路連線與轉址 (Egress)。
  • 在沒有Ingress / LoadBalancer構件下,搭配Kube-Proxy提供最基礎方式的外對內服務接口,也就是K8S內NodePort的機制

目前在開源環境內大家常用的CNI包括了Calico / Flannel / Weave / OVN等等,VMware之前在NSX Data Center內有提供NCP (NSX Container Plugin) 作為於NSX/vSphere部署環境內的CNI功能。而最新的方案則是由VMware Lead,同時有多家公有雲廠商一同參與的開源方案 Antrea。Antrea除了具備所有常見開源CNI的優點外,還能與外部系統如NSX整合,提供企業等級的微分段與網路維運優勢,我們後續待方案成熟會進一步與大家介紹。

2. LoadBalancer / Ingress

當管理者在Kubernetes環境內部署服務,並且想提供給外部用戶連線使用,絕大部分的生產環境內我們都會部署南北向的LoadBalancer / Ingress機制。基本上,

  • LoadBalancer這個服務型態就是標準的L4 Load Balance功能,包含了網路四層基於TCP / UDP協議與對應Port號的基礎負載平衡機制,將外部的連線要求轉發給後端的Pod。
  • Ingress就是標準的HTTP/HTTPS七層負載平衡功能。外部用戶以HTTP/HTTPS往應用進行連線要求,Ingress提供憑證/加解密/表頭檢查與改寫/轉發。簡要來說Ingress包含了網路上的『負載平衡』以及HTTP應用層面要求的『Reverse-Proxy』兩種機制。

在不同的環境內,會採用五花八門的方式來提供LoadBalancer / Ingress機制。有些是平台內建如公有雲,有些是採用開源方案如Nginx / Contour / HA-Proxy,與常見的應用遞送服務廠商的機制來搭配組合。VMware在這邊的方案包含了之前早期的NSX-T Load Balancer,開源的Contour,以及在本系列文內討論的AKO (Avi Kubernetes Operator)。

3. Service Mesh

雖然實際部署在生產環境的案例還沒有太多,但客戶目前在建立新的K8S環境時大概都開始會評估/考慮採用Service Mesh方案。Service Mesh是一個集中管理,但分散運作於每個Pod之前的服務代理架構,通常用來進行各個Service/Pod之間的連線加密、連線品質監控、東西向路徑政策控制等機制。目前在開源環境內大家常聽過的應該包括了Istio / Consul / LINKERD 等方案。VMware則有可跨多個K8S Cluster來集中管理的Tanzu Service Mesh產品。

言歸正傳,後續和大家介紹NSX Advanced Load Balancer內的Avi Kubernetes Operator,就是專門針對上述構件二內的Ingress / LoadBalancer需求提供的方案。透過AKO,我們可以提供跨雲、高效能、功能完善、日誌及分析功能強大的容器南北向應用遞送服務。如何做到,請各位在接續的系列文內,聽我們娓娓道來。

相关文章

评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注