虛擬雲網路

網路虛擬化NSX 技術文章系列二百二十六: NSX Advanced Load Balancer容器方案支持(四):AKO方案架構簡述

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

前文內我們以文字及圖例說明了NSX Advanced Load Balancer (Avi Networks) 內,支持Kubernetes平台應用遞送功能的AKO (Avi Kubernetes Operator) 方案架構。在前篇內談到幾個重點:

  • AKO本身是一個位於Kubernetes叢集內的控制Pod,不經手任何的用戶連線。
  • AKO會將Kubernetes應用管理者提出的應用遞送相關需求,翻譯並轉送給Avi Controller。後續的配置由Controller再配置到服務引擎上
  • 實際應用遞送服務,包含如負載平衡、加解密、Reverse-Proxy的要求,由現有Avi環境內的服務引擎提供。Service Engine是外部環境已建立的虛機或是實體機

簡單的AKO運作架構可以繪製如下:

所以本篇內我想用個實際的環境抓圖給大家看。下圖內是我用來展示的環境,採用Tanzu Kubernetes Grid 1.3.1版運作於vSphere環境內。由vCenter介面,可以看到資源池內有三組環境:

  • 有四台Avi的服務引擎。這些就是實際提供應用遞送服務的Avi虛機,在需要時可以快速地在vSphere環境內新增
  • 有七台開頭為gc-01的虛機,這是我以TKG自動部署機制建立出的Tanzu Kubernetes Cluster (TKC),包含三台master nodes (control-plane) 以及四台worker nodes (md)。實際運作的業務pod就是放在這個cluster內,當然AKO pod也是在此cluster內
  • 四台開頭為tkgm-mgmt-cluster的虛機,這是於vSphere環境內建立的TKG Management Cluster,用來做各個 TKC的建立、擴充、升版等生命週期管理用途。

另外也說明vCenter以及Avi Controller放在外部,沒有在這邊的vSphere Cluster內,因此在上圖內沒有看到。

簡單檢視一下這個gc-01 TKC Cluster,目前採用的是Kubernetes v1.20.5版本

當我們將AKO於此TKC Cluster內安裝完成後,可以看到在avi-system這個namespace內,有運作一個叫做ako-0的pod

檢視一下這個ako-0 pod,可以看到是以Statefulset的方式進行部署,且是由外部projects.registry.vmware.com這個repository拉下來的,目前是1.4.2版

接著用兩個應用做舉例。首先是一個簡單的投票系統應用,讓用戶可以連線進來投票哪家餐廳好吃。下圖是此應用部署的Pod:

要讓外面用戶可連到此應用,我們建立了一個LoadBalancer Service走TCP 80 port。同時,我們也指定了這個Load Balancer的外部IP為172.20.14.249,如下圖:

當AKO看到Kubernetes Cluster內要部署上述的配置,如我們前面描述,會將相關需求的配置自動送給Avi Controller,並由控制器在外部服務引擎上建立需求的Virtual Service以及後端的Pool配置。下圖是AKO要求Avi Controller對應這個LoadBalancer Service所建立的Virtual Service叫做gc-01–yelb-app-yelb-ui。我們點進去看到配置為

  • Virtual IP如同Service配置檔,設定於172.20.14.249
  • 採用System-L4-Application這個profile (L4 Application),並且走TCP 80 port

此時,外部用戶就可以用瀏覽器連往http://172.20.14.249,來進行想要的餐廳投票了。

第二個例子是一個購物商城,部署的Pod如下:

這裡我們採用Ingress的方式讓外面用戶連到此應用。下圖看到建立了一個Ingress,因為有啟用tls,代表是採用HTTPS並有帶憑證。同時,我們也指定對應此Ingress的FQDN是acme-fitness.tkgm.sysage.com。收到要求後,要送往後端名稱為frontend的服務,往port 3000傳送。

對應到Ingress,Avi會採用Virtual Hosting的方式來處理,依據管理者要求,一個Virtual IP可以給多個域名FQDN共享(但當然也可獨享)。細節先不談,在AKO監控到Kubernetes Cluster內有上述Ingress要求後,會對Controller提出要求建立對應的HTTPS Virtual Service。在Avi的管理介面內可以看到對應的兩個Virtual Service,下面的gc-01–ako-infra-setting-vip-acme-fitness.tkgm.sysage.com-dedicated 這個是parent VS,對應了172.20.14.234這個IP地址。上面的gc-01–ako-infra-setting-vip-acme-fitness.tkgm.sysage.com這個則是對應acme-fitness.tkgm.sysage.com的Child Virtual Service:

展開這個Child Virtual Service的配置給大家看,AKO自動配置了

  • 對應acme-fitness.tkgm.sysage.com這個域名的Child Virtual Service
  • 應用型態為HTTPS (System-Secure-HTTP)
  • 自動將ingress YAML檔內的憑證放入SSL Certificate

當然,此時終端用戶就可以用瀏覽器連往https://acme-fitness.tkgm.sysage.com,來連到這個購物商城大買特買了。

在本篇內我們用了很多圖例示範AKO的基本使用情境,後續在相關進階說明內也會繼續採用這邊的環境。再回到本篇訴求的重點:NSX Advanced Load Balancer使用在容器架構時,AKO方案

  • 僅需要在Kubernetes叢集內建立一個控制Pod。
  • 此AKO控制Pod管理者提出的應用遞送相關需求,轉送給Avi Controller,由Controller配置到服務引擎上
  • 實際應用遞送服務由現有Avi環境內的服務引擎提供

這樣的架構可以提供什麼樣的好處呢?在下篇繼續與大家說明。

相关文章

评论

发表评论

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