虛擬雲網路

網路虛擬化NSX 技術文章系列二百四十: NSX Advanced Load Balancer容器方案支持(十八):常見問題討論

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

經過漫長對於NSX Advanced Load Balancer (Avi Networks) 內的容器整合方案AKO (Avi Kubernetes Operator) 相關介紹,終於到了系列文的最後一篇。本篇內我想就與客戶及經銷夥伴進行AKO的方案說明及展示時,常被詢問的問題以FAQ的方式進行整理與回覆。

如果要使用AKO,需要額外的授權嗎?

不需要,以前我們介紹過,當企業購買NSX Advanced Load Balancer的授權時,是全功能的。因此只要有購買Service Core啟用需求的服務引擎vCPU,AKO當然可以使用。

講細一點:

  • 若是在自建原生K8S、Openshift、公有雲內的管理K8S(如AWS EKS, Azure AKS, GCP GKE)上面要用AKO運作於NSX Advanced Load Balancer,此時企業原本就需要購買相對應的NSX ALB Service Core授權,這個授權內原本就包含了AKO的功能。
  • 若企業買VMware Tanzu在私有雲內自建,或是在公有雲上部署Tanzu Cluster。此時如果是購買Tanzu Advanced以上的版本,裡面就已經有包含NSX Advanced Load Balancer的授權了(每4顆Tanzu Advanced CPU授權提供一顆NSX ALB Service Core)。
  • 若企業是購買Tanzu Basic或是Tanzu Standard的版本,此時授權內並沒有內含NSX Advanced Load Balancer (與AKO)。但AKO的功能很吸引你?沒問題,多花一點錢加買幾個NSX ALB Service Core就好啦~

AKO內是否可進行路徑控制,來對應金絲雀發布 / 灰度發布等需求?

這個功能很重要,比如說在Nginx內會使用”canary”,Openshift Route內採用weight,而Contour內是叫做HTTPProxy。基本上,當管理者要進行應用升版時,很可能不是瞬間全部切換,而希望能透過權重、表頭、cookie等不同機制來控制哪些/多少用戶連線要送往新版本,哪些要留在舊版本,逐步地進行升版的移轉。

本文寫作的AKO 1.4.2版此功能尚未支援,這是目前我認為AKO最需要補強的重點功能之一。希望屆時實現後再與各位進行介紹。

在Tanzu with vSphere on NSX-T架構內是採用NSX-T本身的Load Balancer,與AKO有何不同?

是的,Tanzu with vSphere on NSX-T架構內,Tanzu Kubernetes Cluster (Guest Cluster) 的前端是採用NSX-T Load Balancer提供LoadBalancer Service。而如果希望採用Ingress,現時的標準做法是安裝Contour。這其實很接近我們前面討論的傳統架構。

此架構內,請把NSX-T Load Balancer就當作一個很基本的L4負載平衡器來看待。前面我們提到NSX Advanced Load Balancer相關的強項,包含效能與橫向擴充、日誌、進階功能等等,在此方案內都沒有。這也是VMware建議客戶後續逐步採用NSX ALB的原因。

VMware在2022年中應該會有整合AKO與Tanzu with vSphere on NSX-T的自動配置步驟。現在時間點如果堅持一定要使用AKO,確實可以手動安裝,但因為不是官方建議的標準架構,就不和大家多談了。

之前有聽過Avi Networks有Kubernetes/Openshift Cloud,與AKO有何不同?

Kubernetes/Openshift Cloud是Avi Networks早期的容器環境支持方案。與AKO的架構截然不同,服務引擎是採用容器形式直接運作在K8S叢集內。因為包含效能等種種問題,現在已經宣告停止支持了。

AKO是目前NSX Advanced Load Balancer唯一建議採用的應用遞送容器整合方案。

AKO有自己的版本,與NSX Advanced Load Balancer如何進行搭配?與其他Kubernetes的環境如何進行搭配?

於寫作本文當時,NSX Advanced Load Balancer為20.1.6版,AKO為1.4.2版。並非1:1的版本對應,AKO的1.4版本在NSX ALB 20.1.4版之後都可支援。簡而言之,這邊在安裝前請大家參考AKO的相容性文件:https://avinetworks.com/docs/ako/1.4/ako-compatibility-guide/

這份文件內包含了

  • AKO支持的不同Kubernetes原生及商用版本。
  • AKO支持的Container Network Interface種類。
  • AKO支持的不同種類公私有雲環境。
  • AKO版本與對應可支持的NSX Advanced Load Balancer版本。

等相關資訊。請務必於實際配置前查詢。

可否總結一下AKO的效益?

當然。回到本系列文開頭很前面的時候,有和大家討論在容器環境內,應用遞送服務的需求要件如下:

本系列文內花了這麼長的篇幅,就是希望能夠讓大家看到上述的需求,在NSX Advanced Load Balancer的AKO方案內能夠被滿足:

  • AKO支持標準的LoadBalancer / Ingress配置,也透過自訂Customized Resource Definition如HostRule / HTTPRule / AviInfraSetting等讓管理者透過YAML檔進行完整的應用遞送配置於重要業務前。
  • 搭配NSX Advanced Load Balancer的架構,應用遞送功能於虛機 / 實體機上執行而非效能較差的容器。同時,透過Active-Active架構,可於需要時快速進行效能擴充
  • 提供完整交易日誌紀錄分析、WAF、GSLB等完整功能。
  • 支持在不同公私有雲、自建或管理環境,與不同Kubernetes原生及商用版本內運作。
  • 後續支持HTTPProxy南北向路徑控制、連線分派完整功能。

到此,謝謝大家耐心看完系列文章,希望讓各位對AKO方案在容器環境內的效益、架構、進階功能等有進一步認識。

相关文章

评论

发表评论

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.