虛擬雲網路

網路虛擬化NSX 技術文章系列二百二十五: NSX Advanced Load Balancer容器方案支持(三):AKO方案架構簡述

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

本篇內我想要開始就NSX Advanced Load Balancer (Avi Networks) 內支持Kubernetes平台的AKO (Avi Kubernetes Operator) 方案架構進行介紹。VMware在2020年中提出第一個AKO生產版本,取代原本Avi Networks內Kubernetes Cloud的機制,作為各種不同Kubernetes容器平台應用遞送服務的新一代支持方案。在寫作本文的此時是1.4.2版,AKO可以部署於下列不同Kubernetes平台內:

Kubernetes方案對應支持版本
原生 KubernetesVersions 1.16, 1.17, 1.18, 1.19, 1.20, 1.21
OpenshiftVersions 4.3, 4.4, 4.5, 4.6
Tanzu Kubernetes Grid
(TKG Multi-cloud)
Versions 1.2, 1.3
vSphere with Tanzu
(TKGS)
vSphere 7.0U2

AKO可以運作於不同的公私有雲環境,在自建或是平台內建的Kubernetes環境進行部署:

Kubernetes部署方式 vCenter (VDS) VMC AWS Azure GCP
自建 Kubernetes v v v v v
自建Openshift v v v v
平台管理Kubernetes v v v
Tanzu Kubernetes Grid
(TKG multicloud)
v v v v
vSphere with Tanzu (TKGS) v

無論是在哪一種環境,我們可以用下圖來概括說明AKO的架構:

簡單說明在上圖內的各項構件:

Avi Controller

就是我們NSX Advanced Load Balancer的控制器。若大家對Controller功能尚不熟悉,很快回憶一下,Controller的主要功能為

  • 提供集中化的組態與自動化管理,並將應用遞送需求建立的配置需求發送至服務引擎。
  • 提供服務引擎本身的維運管理,包含自動配置服務引擎,擴充、服務轉置、刪除、確認服務引擎的健康狀態、HA切換控制等作業
  • 收集來自服務引擎對於應用遞送服務的相關日誌與效能資訊,進行統計分析供管理者進行後續查找

Avi Service Engines

就是我們NSX Advanced Load Balancer的服務引擎。相同地回憶一下,Service Engine的主要功能為

  • 實際上提供應用連線遞送處理,包含了本地與全域負載平衡、連線轉發、SSL加解密、WAF規則檢查、Log日誌以及metric效能產出等作業。
  • 服務引擎之建立與管理作業透過Controller來進行,無需進行任何本地配置
  • 服務引擎可以是虛機或實體機型態
  • 服務引擎可以依需求於底層資源池(vSphere, 公有雲)動態產出,提供Scale-Up或Scale-Out效能擴充

上面這些都是我們在多篇網誌內反覆說明的NSX Advanced Load Balancer現有機制。而在容器方案內,還有第三個核心構件是

Avi Kubernetes Operator

Avi Kubernetes Operator 實際上單純是一個Kubernetes叢集內的Pod。這個Pod本身沒有任何實際應用遞送封包轉發的功能,而是一個用來監控Kubernetes配置的控制元件。AKO Pod會檢視K8S環境內用戶關於LoadBalancer Service / Ingress,以及相關應用遞送配置如HTTPRule / HostRule / 底層資源需求等CRD (Customized Resource Definition) 要求,並將這些要求轉送給Avi控制器進行需求的應用遞送配置。

下圖內是一個簡要的AKO運作流程:

  1. 應用管理者透過YAML檔,建立應用並配置需求的 Ingress / LB Service
  2. AKO取得配置資訊
  3. AKO 轉譯上述應用遞送需求,透過 Avi APIs 告知控制器
  4. AVI 控制器由 IPAM 服務配置 VIP,並將 Ingress 內定義之FQDN (host) 發佈至 DNS
  5. AVI控制器發布對應的Pool / Virtual Service 到服務引擎,建立對應此Ingress / LB Service需求的應用遞送服務

此時這個應用管理者要建立的Ingress (L7 HTTP/HTTPS) 負載平衡服務就在Avi服務引擎上啟用了。那麼當終端用戶要連線到這個服務時呢?以連線到一個Ingress服務為例:

  1. 用戶透過FQDN要連往服務,瀏覽器詢問DNS。由DNS收到回應此FQDN對應的地址,即為對應的Virtual IP
  2. 瀏覽器發送連線需求到 Virtual IP (在 Avi 服務引擎上)
  3. Avi 服務引擎進行需求的憑證發送、加解密、表頭檢視,並基於負載平衡機制,選擇後端一個 pod 進行連線發送
  4. 用戶連線轉送至後端 Pod
  5. Pod 連線回傳

上述的架構與配置機制我們會在後面進一步說明。但這邊我想先就上述的AKO架構進行一個重點整理:

  • AKO機制是建立在現有的NSX Advanced Load Balancer (Avi Networks) 架構上,並非獨立方案。方案內採用與標準NSX ALB完全一致的Controller / Service Engine架構。
  • AKO本身是一個控制Pod,不經手任何的用戶連線。
  • AKO唯一的責任,就是將Kubernetes應用管理者提出的應用遞送相關需求,翻譯並轉送給Avi Controller。後續的配置由Controller再配置到服務引擎上
  • 所有Ingress / LoadBalancer負載平衡、加解密、Reverse-Proxy的要求,在Service Engine上處理。Service Engine可以是虛機或是實體機,但並非K8S Pod
  • 因為所有應用遞送需求就是實際在Avi現有環境內部署,因此Avi本身提供的日誌檢視、Web Application Firewall等功能與維運機制,都可以實現於對應的容器服務上。

先停在這邊。我想光是用文字加簡單圖例的敘述應該還不夠,下篇我會抓一些實際的畫面與配置給大家看,希望讓各位對AKO的架構、運作與使用有進一步的理解。

相关文章

评论

发表评论

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