作者： 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方案 | 對應支持版本 |
| 原生 Kubernetes | Versions 1.16, 1.17, 1.18, 1.19, 1.20, 1.21 |
| Openshift | Versions 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運作流程：
- 應用管理者透過YAML檔，建立應用並配置需求的 Ingress / LB Service
- AKO取得配置資訊
- AKO 轉譯上述應用遞送需求，透過 Avi APIs 告知控制器
- AVI 控制器由 IPAM 服務配置 VIP，並將 Ingress 內定義之FQDN (host) 發佈至 DNS
- AVI控制器發布對應的Pool / Virtual Service 到服務引擎，建立對應此Ingress / LB Service需求的應用遞送服務
此時這個應用管理者要建立的Ingress (L7 HTTP/HTTPS) 負載平衡服務就在Avi服務引擎上啟用了。那麼當終端用戶要連線到這個服務時呢？以連線到一個Ingress服務為例：
- 用戶透過FQDN要連往服務，瀏覽器詢問DNS。由DNS收到回應此FQDN對應的地址，即為對應的Virtual IP
- 瀏覽器發送連線需求到 Virtual IP （在 Avi 服務引擎上）
- Avi 服務引擎進行需求的憑證發送、加解密、表頭檢視，並基於負載平衡機制，選擇後端一個 pod 進行連線發送
- 用戶連線轉送至後端 Pod
- 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的架構、運作與使用有進一步的理解。
Comments
0 Comments have been added so far