虛擬雲網路

網路虛擬化NSX 技術文章系列二百二十七: NSX Advanced Load Balancer容器方案支持(五):AKO與傳統應用遞送架構之差異

作者: 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方案較傳統架構有哪些優勢呢?我在下篇網誌想繼續和大家討論。

相关文章

评论

发表评论

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