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

前兩篇網誌內我們討論了NSX Advanced Load Balancer (Avi Networks) 的Kubernetes解決方案：AKO (Avi Kubernetes Operator) 的基礎運作架構，以及相關的運作畫面。在進一步說明細部架構與進階功能前，我想要先暫停，在本篇討論一個話題：AKO的運作架構，與現行一般企業容器生產環境的傳統應用遞送方案架構有何不同？差異點為何？

簡單討論一下我們通常在現行已經建置Kubernetes客戶所看到的應用遞送架構。由下到上，完整方案內在核心業務前通常要有包含L7 Reverse-Proxy / L4 Load Balancer / Web-Application Firewall / Global Server Load Balancing等機制：

L7 Reverse-Proxy

通常我們在客戶端看到的主要會是開源方案，像是Nginx Ingress Controller / Contour 這些。如前面討論的，L7 Reverse-Proxy會負責HTTPS憑證、加解密、HTTP表頭解析、改寫、轉送等等功能。

在大部分開源環境內，這些reverse-proxy方案會是以Pod的方式來進行部署，直接住在Kubernetes Cluster裡面。而這些Ingress-Controller (Reverse-Proxy) Pod則通常會以Nodeport的形式讓前端Load Balancer或外部用戶進行連線。比如說，外部用戶可以連到任何一台Kubernetes Worker Node的31002 port來連接Ingress-controller pod。

Enterprise-Grade L4 Load Balancer

但實務面上我們當然不會讓終端用戶去連這些31002這種port。因此大部分開源Kubernetes方案前端仍會放置一組企業等級的Load Balancer，或許是F5 / Netscaler，或像是開源的HA-Proxy，或是公有雲的內建Load Balancer。在這一層，通常做的僅是標準的L4負載平衡，比如說設定服務對外的VIP，當用戶連接到這個VIP的TCP 443 (HTTPS) 或 80 (HTTP) Port時，把它轉送到後端Ingress Controller的對應IP/Port（前面所提的Worker-Node-IP/3XXXX Port）。

這層方案通常依據企業環境需求，可能是實體的負載平衡器，也可能是虛機型態的Appliance。

Web Application Firewall

通常在客戶生產環境內，有前面的L7 Reverse-Proxy / L4 Load Balancer已可運作了。但如果是重要的Internet服務，前面不擺個Web Application Firewall來阻擋常見的Web攻擊很奇怪吧。因此大型客戶在前面可能又會擺Imperva / F5等等WAF方案，來做需求的Web連線檢查

Global Server Load Balancer

那再往前，如果我們的重要業務會跨地區 / 跨Site部署，此時最前端有Global Server Load Balancer也很合理，因為企業需要確認各個Site的服務可用性，必要時進行連線切換，或依據終端用戶在不同地區，連結到地理位置上比較近的服務站點。那這一層是不是又需要再放一層企業等級的GSLB方案呢？

如果各位有實際參與過基於Kubernetes平台的業務部署考量的話，上面這邊我們談的架構應該不陌生。好，如果現在企業是改採用AKO方案來進行部署的話，如前面幾篇所述，那架構會是怎麼樣？

如同前兩篇介紹的，我們會放一個叫AKO的控制Pod在Kubernetes Cluster內。但所有真正的應用遞送需求，包含L7 Ingress / L4 Load Balancer / Web Application Firewall / Global Server Load Balancing等等，都可於外部的Avi服務引擎上，以單一管理介面、單一方案來進行。

這裡我想要與大家指出在傳統架構，以及採用Avi AKO方案，這兩種設計，在架構上的差異性：

  • 傳統架構內，這些不同的應用遞送需求，會由4個不同的方案/設備各自提供，有獨立的配置與各自的管理機制。在AKO方案內，這些所有的應用遞送功能都可以單一的NSX Advanced Load Balancer方案進行配置與管理。
  • 在傳統方案內，雖然前端的GSLB/WAF/L4 LB都是採用實體設備或虛機，但是負責重要HTTPS加解密、封包檢查與表頭改寫的L7 Reverse-Proxy基本上都是Pod。在AKO方案內，上述所有功能會是在Avi Service Engine (服務引擎)內運作，服務引擎可依管理者選擇，採用實體伺服器或是虛機。
  • 一個HTTPS連線進來，在傳統架構內需要兩次加解密 (WAF / L7-Reverse-Proxy)，而憑證也要各自擺放在這兩個設備內。在AKO架構內，因為WAF / L7 HTTPS可以直接在單一Virtual Service內提供，加解密與憑證管理都僅只需要在同一個方案內進行。

基於上述的架構差異，會讓NSX Advanced Load Balancer的AKO方案較傳統架構有哪些優勢呢？我在下篇網誌想繼續和大家討論。