作者： 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方案在容器環境內的效益、架構、進階功能等有進一步認識。