作者： Colin Jao 饒康立 – VMware資深技術顧問，主要負責VMware NSX產品線，目前致力於網路虛擬化、分散式安全防護技術與新應用遞送方案的介紹與推廣。
這一篇內我們要討論AKO (Avi Kubernetes Operator) 內的另一個進階擴充功能叫Avi Infra Setting。這個CRD物件與前篇討論的HostRule / HTTPRule功能目的完全不同，主要用於要對應到Kubernetes叢集內不同LoadBalancer Service / Ingress的資源需求配置。
什麼意思呢？請先想一下AKO標準的配置，基本上在初始設定內，
- 同一個Kubernetes Cluster內的所有LoadBalancer / Ingress都是共享同一個服務引擎群組 (Service Engine Group)。
- 雖然這些服務引擎是採用虛機或實體機而非容器，且可以橫向擴充因此效能較佳。但初始配置內無法給特定的重要業務獨立的運算資源。
- 所有LoadBalancer / Ingress都是共用同樣設定於AKO value.yaml檔內的Virtual IP網路。不容易將底層網路分開
- 在Ingress內，預設值是多個Ingress共享數個Virtual IP。但生產環境內可能某些特定的重要服務需要自己獨立的Virtual IP
上面這些不是AKO這個方案本身的問題，其實幾乎所有的容器應用遞送方案都差不多。但在大型生產環境內，客戶常會希望就他們最重要的核心業務，方案內可以提供
- 獨立的應用遞送資源（服務引擎），專門給這個核心業務用。避免其他業務流量大有效能問題時，影響到這個重要核心業務
- 獨立的Virtual IP，不要和其他業務混用。這樣企業網路內可以專門針對誰能連到這個核心業務設定防火牆配置
Avi Infra Setting這個CRD就是為了上述目的設計的。直接與大家舉例。請回憶一下我們在之前網誌用來示範的環境，示意如下：
當我們在建立此環境的AKO配置時，value.yaml內對於環境配置的相關變數是下列這些。這裡我只列出相關的部分，無關的就省略：
NetworkSettings: subnetIP: ‘172.20.14.0’ subnetPrefix: ’24’ enableRHI: false vipNetworkList: – networkName: “TKGM-Workload-vlan4014” L7Settings: shardVSSize: LARGE ControllerSettings: serviceEngineGroupName: “TKGM-SEG-AA” |
上面是什麼意思呢？這代表在此Kubernetes叢集內，AKO安裝的基礎配置是
- 各個LoadBalancer / Ingress服務會指派的Virtual IP，採用”TKGM-Workload-vlan4014″這個Port Group內定義的範圍
- 多個Ingress可以共享Virtual IP（shardVSSize設定為LARGE）
- 所有LoadBalancer Service / Ingress採用的服務引擎是在”TKGM-SEG-AA”這個Service Engine Group內定義且建立的服務引擎
因此在前面的應用規劃內，大家可以看到dashboard / dvwa這兩個ingress就是共用同樣的Virtual IP。此外，所有的Virtual Service，包含DNS Service / Yelb / KUARD / dashboard / dvwa等等，都是使用TKGM-SEG-AA這個群組內的服務引擎
但現在需求是acme-fitness這個應用因為很重要，所以需要能夠有獨立的服務引擎，以及自己的Virtual IP。此時首先，我們在Avi環境內建立了一的獨立的服務引擎群組叫做VIP-APP-Group，而且特別設定了需求的服務引擎資源要比較大（下圖內設定 vCPU x4, Memory x8GM, Storage x50GB）
接著，我們使用下列的Avi Infra Setting配置出一個獨立資源：
apiVersion: ako.vmware.com/v1alpha1 kind: AviInfraSetting metadata: name: ako-infra-setting-vip spec: seGroup: name: VIP-APP-Group network: names: – TKGM-Workload-vlan4014 enableRhi: false l7Settings: shardSize: DEDICATED |
上面這個AviInfraSetting的CRD內，我們進行了下列特殊的資源定義：
- 採用的服務引擎群組是VIP-APP-Group
- 要採用的Virtual IP網路範圍是定義於TKGM-Workload-vlan4014這個Port Group內（這邊的配置與原本預設配置相同，沒有改變）
- 每個Ingress要獨立有自己的Virtual IP (shardSize配置為DEDICATED)
這邊的資源定義完成後，接著，我們可以用標準在Kubernetes 1.19後，networking.k8s.io/v1 內的IngressClass / Ingress來呼叫上面的資源配置。首先建立一個IngressClass:
apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: name: ako-ingress-class-vip spec: controller: ako.vmware.com/avi-lb parameters: apiGroup: ako.vmware.com |
簡單說明上面這幾行，我們建立了一個叫做ako-ingress-class-vip的IngressClass，請想像就是一個可獨立呼叫的K8S Ingress Controller。這個IngressClass內，呼叫的是我們前面所定義的AviInfraSetting內的資源定義 (ako-infra-setting-vip)。
所以應用管理員在建立acme-fitness這個應用的Ingress時，如果需要獨立資源，就額外呼叫上面的IngressClass即可，像下面這樣：
— apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: frontend-ingress spec: ingressClassName: ako-ingress-class-vip tls: – hosts: – acme-fitness.tkgm.sysage.com secretName: acme-fitness-secret rules: – host: acme-fitness.tkgm.sysage.com http: paths: – pathType: Prefix path: / backend: service: name: frontend port: number: 3000 — |
透過上面這樣的配置，首先很明確在前面網誌已經有說明，這個應用有拿到自己的獨立IP，前面的圖有繪出是獨立的172.20.14.234，無需與其他Ingress分享。其次，我們要求要獨立的服務引擎。請看下面的兩張圖，首先是TKGM-SEG-AA這個群組：
上圖內可以看到，服務引擎是Avi-se-ytffd / Avi-se-cmfbv這兩台，此外除了acme-fitness以外的所有Virtual Services，都是在這組服務引擎內。
但在VIP-APP-Group這個服務引擎群組呢？
首先，服務引擎是Avi-se-zsqfr與Avi-se-beszs，與前面的Service Engine是不同的（資源獨立）。而這個群組內，只有acme-fitness這個ingress產出的Virtual Service使用。
由上面的舉例，希望讓大家可以看到藉由Avi Infra Setting這個進階功能，讓我們可以很方便地在大型生產環境內區分各個業務獨立的運算及網路資源。這件事情重不重要？想看看，要進行加解密的Ingress服務，流量大時如SSL-Offload / WAF等都很容易大量佔用運算資源。當Kubernetes Cluster內有多個重要業務，適當地將應用遞送的運算與網路資源拉開是很需要的。
另外額外補充，上面我們討論的是Ingress。大家可能會問，LoadBalancer Service內可否進行類似的資源區分？可以，但這邊搭配的不是LoadBalancer Service，而會是Kubernetes內新的Gateway API / GatewayClass架構，這邊就不多談了。
後面會是本系列的最後一篇，我想採用FAQ的方式，回應在與客戶及經銷夥伴介紹AKO時的一些常見詢問。
Comments
0 Comments have been added so far