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

接續前面數篇網誌，我們討論了NSX Advanced Load Balancer (Avi Networks) 內Kubernetes解決方案：AKO (Avi Kubernetes Operator) 的基礎運作架構，也比較了與傳統容器生產環境的應用遞送方案部署方式。本篇內我想直接回應一個問題：採用AKO方案與傳統架構相比，有何優勢？

回憶一下上篇的架構比較：

應用遞送服務效能面：

AKO方案的整體應用遞送效能會較好。大家可能會覺得違反直覺，與企業等級的這些硬體負載平衡器，又有晶片作加解密的，AKO方案的效能怎麼會較好呢？下面幾點來進行討論：

  • 傳統容器應用遞送架構內，GSLB / WAF / L4 Load Balancer是高效能的硬體設備沒錯，但核心的L7 Reverse-Proxy絕大部分都是Kubernetes Pod。這些Pod需要進行HTTPS加解密、封包檢查與表頭改寫等大量需要運算資源的工作，在大型生產環境高併發流量時，採用Pod提供上述功能極為考驗運算能力
  • AKO方案內，上述功能在Avi Service Engine (服務引擎)內運作，服務引擎可依管理者選擇，採用實體伺服器或是虛機，基礎運算能力明顯優於Pod。
  • 在NSX Advanced Load Balancer方案內，一個Virtual Service (對應到上述的L7 Reverse-Proxy / L4 Load Balancing) 是可以在多台服務引擎上，以Active-Active架構運作的，管理者可考量需要時進行Scale-Up / Scale-Out。這代表在大型生產環境內，管理者可隨時依據需求擴充Avi服務引擎以提升應用遞送效能
  • AKO架構內，允許讓各自應用之Ingress使用獨立的服務引擎提供服務，而開源方案基本上在同一個Kubernetes Cluster內的所有應用通常會共用相同的Ingress Controller (L7 Reverse-Proxy Pod)。這樣的資源調配自由讓AKO可以提供重要業務獨立、不受其他應用干擾的應用遞送能力。我在後面的網誌就此點會更進一步說明

下圖內可看到，在提供之前網誌內示範的購物網站，我們可以透過三台服務引擎來提供服務，且在需要時再Scale-Out，進一步提升效能

維運及自動化：

傳統方案內，需要多個獨立產品組合出完整功能。功能面或許可達成，但在維運面上

  • 管理者需要在各自不同方案內進行獨立的配置與各自的管理機制。
  • 多種方案不一定都能在Kubernetes內透過YAML配置，需手動管理。比如說重要對外網路業務前要配置WAF，應用管理者無法自行於K8S或應用部署流程內，啟用WAF的功能
  • 憑證管理需要在多個獨立構件內各自配置
  • 如果牽涉到跨雲部署，在不同雲方案內可能採用的Load Balancer / WAF等機制都不同，更加增添部署複雜性

而在AKO方案內，這些所有的應用遞送功能都可以單一的介面進行配置與管理，並在需要時透過YAML檔直接呼叫。若在跨雲架構部署，管理介面與提供的功能均為一致。

架構面：

傳統架構內利用多組方案提供不同功能，這代表單一用戶連線，需要在多組的設備內不斷跳轉。這造成

  • 連線延遲時間加大
  • 不同功能可能部署在不同的安全區，代表單一用戶連線會跨不同安全區建立，底層防火牆配置複雜
  • 多種設備與跨環境運作造成連線問題檢查複雜化

成本面：

傳統架構內企業需要採購多組方案，同時也須考量對應之訓練及維運成本。NSX Advanced Load Balancer於此處的優勢包括

  • 單一授權即提供完整應用遞送功能
  • 彈性授權機制不受限於硬體設備，資源易於彈性擴充與調動
  • 管理人員訓練及維運簡易

功能面：

在之前多篇對於NSX Advanced Load Balancer的介紹內便說明，Avi對應雲原生應用在設計上補足了許多傳統方案的不足。比如說，重要的業務雖然改採用容器部署…各位會想要看到這個業務的相關統計資訊、甚至單一交易的日誌內容吧？像是下面兩張圖所示：

暫時停筆。如同大家常講的，『現代的問題要以現代的手段解決』，而為什麼企業要轉為改用容器平台部署核心業務？因為這才能易於搭配敏捷開發、資源隨需調用、自動化、快速部署的好處啊。而如果我們在應用遞送部分仍然採用二十年來的傳統架構，只有在後端容器平台自動化，那不是影響到整體應用架構轉換的最重要效益了嗎？在雲原生架構內，也應該要採用因應雲原生架構設計的應用遞送方案，這也是我們不斷與大家介紹的訴求。