虛擬雲網路

網路虛擬化NSX 技術文章系列二百三十三: NSX Advanced Load Balancer容器方案支持(十一):前端網路配置及DNS整合

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

在一個標準的Kubernetes環境內,基本上AKO (Avi Kubernetes Operator) 需要處理的就是LB Service以及Ingress這兩種配置,另外在Openshift內還有專屬的Route型態。在本篇內,我想說明AKO是如何處理各種應用遞送服務要求,轉譯為NSX Advanced Load Balancer內的Virtual Service。這邊會用與前一篇相同的環境來進行舉例,因此這邊把前篇的兩張圖再抓回來如下。

我們在標準Kubernetes內要讓外部用戶可存取應用時,會採用下列這幾種方法:

1. Service Type: LoadBalancer

在此型態內,AKO會要求Avi Controller建立一個L4 Application型態的Virtual Service。直接以下面的YAML檔舉例,這是上圖內應用2號:KUARD裡的Load Balancer配置:


## Kuard LB                                    
                                               
apiVersion: v1                                 
kind: Service                                  
metadata:                                      
  name: kuard-lb-svc                           
  labels:                                      
    Application: kuard                         
  namespace: kuard-ns                          
spec:                                          
  type: LoadBalancer                           
  ports:                                       
  – port: 80                                   
    protocol: TCP                              
    targetPort: 8080                           
  selector:                                    
    Application: kuard

上面的配置內,

  • AKO要求啟用一個L4 Application型態的Virtual Service,對外聽取TCP 80 port
  • Virtual IP會由Avi Controller內預先配置的Pool內動態選取,在此範例內,拿到的是172.20.14.237這個IP
  • 往後會送到有標籤 Application: kuard的pod上的8080 port

下面兩張圖內我們看到對應到這個應用的Virtual Service以及相關的Pool,可看到這是一個標準的L4 Load Balancing機制。

其次在LB Service內,應用管理者是可以指定 IP 的。下面是前面應用1號:Yelb內的LoadBalancer配置。透過加上”loadBalancerIP”設定,我們指定了這個Load Balancer Service的對外IP必須是172.20.14.249

—                                            
apiVersion: v1                                 
kind: Service                                  
metadata:                                      
  name: yelb-ui                                
  labels:                                      
    Application: yelb                          
    Tier: yelb-ui                              
  namespace: yelb-app                          
spec:                                          
  type: LoadBalancer                           
 
loadBalancerIP: 172.20.14.249
                
  ports:                                       
  – port: 80                                   
    protocol: TCP                              
    targetPort: 80                             
  selector:                                    
    Application: yelb                          
    Tier: yelb-ui                              

Service Type: Load Balancer內的配置三個重點很快與大家提醒一下:

  • 每個Load Balancer服務都會取得一個獨立的VIP,是1:1的關係
  • 如果要明確指定Load Balancer VIP,這個IP必須是在VIP Pool範圍內。以上面例子舉例,應用管理者要求172.20.14.249,是在我們預先配置的172.20.14.231~172.20.14.250範圍內。只要這個IP尚未被使用,就可以正常派發運作
  • 接上條,但如果這個指定的IP沒有在VIP Pool範圍內,比如說指定了172.20.14.100 (不在231~250範圍),或是雖然在範圍內,Avi內的IPAM機制發現這個IP已經被其他服務使用了,此時Avi就不會派發IP給這個Load Balance服務。

2. Ingress

AKO可以支持在K8S 1.18版前的networking.k8s.io/v1beta1,以及1.19版後的networking.k8s.io/v1兩種API resource,Ingress要用哪種版本的語法撰寫都可以。當AKO看到應用管理員配置一個Ingress出來時,

  • 如果此Ingress內沒有tls宣告,代表要啟用一個L7 HTTP (80 port) 的七層服務
  • 如果此Ingress內有tls宣告,代表要啟用一個L7 HTTPS (443 port) 的七層服務

在Ingress配置內,預設是多個Ingress服務會共享Virtual IP,在AKO內稱其為Shard機制。當初之所以這樣設計是因為希望節省對外IP,在公有雲內可以省點錢。但如果管理者要求,我們仍然可以配置讓一個Ingress自己有一個獨享的Virtual IP。

很快速解釋Ingress內的Shard / Virtual IP取用機制:

  • 多個Ingress,包含HTTP / HTTPS不同型態,會共享Virtual IP
  • 一個Virtual IP可以對應到多少個Ingress (FQDN Host),可以在AKO的配置內設定,如Large / Medium / Small / Dedicated。
  • 每個Ingress會基於本身的FQDN Host做hash後,決定要放到哪個Virtual IP內。因此只要Host沒有改動,對外使用的Virtual IP都會一致
  • 目前的版本,應用管理者無法指定Ingress要採用的Virtual IP

用前面環境內應用4號:DVWA的Ingress配置來做舉例

 
# Ingress Rule for N/S Load-Balancing         
apiVersion: networking.k8s.io/v1               
kind: Ingress                                  
metadata:                                      
  name: dvwa-ingress                           
  namespace: dvwa-ns                           
spec:                                          
  tls:                                         
  – hosts:                                     
      – dvwa.tkgm.sysage.com                   
    secretName: dvwa-secret                    
  rules:                                       
  – host: dvwa.tkgm.sysage.com                 
    http:                                      
      paths:                                   
      – pathType: Prefix                       
        path: /                                
        backend:                               
          service:                             
            name: dvwa-svc                     
            port:                              
              number: 80

上述例子的YAML配置內,

  • 採用新版networking.k8s.io/v1的API Resource
  • 配置tls,憑證內容建於dvwa-secret內,對應dvwa.tkgm.sysage.com這個host
  • 往後是轉送給在dvwa-svc這個service內pod的80 Port

當AKO讀取此要求,行為則是告知Avi Controller:

  • 這個Ingress對應的Hosts (FQDN) 是dvwa.tkgm.sysage.com,做Hash運算後,Avi Controller會在上層的gc-01–Shared-L7-7這個Parent Virtual Service內,建立一個Child Service來對應dvwa.tkgm.sysage.com這個ingress服務(簡而言之,就是SNI: Server Name Indication機制)
  • 因此這個Ingress服務會使用的是gc-01–Shared-L7-7這個Parent Service的Virtual IP: 172.20.14.233。這個IP當然也是由前面VIP Pool範圍內所動態派送出來的
  • 因為有配置tls,當然這個Virtual Service必須是L7 HTTPS,提供SSL Termination的作業
  • 同時,AKO會自行抓取對應此Ingress服務的憑證,送往此Virtual Service內。
  • AKO會要求Avi Controller建立對應的Datascript,來建立Ingress Virtual Service與後端Pool的對應。

上面的相關機制如果大家有興趣做進一步研究,可以到Avi網站內” Handling of Kubernetes/ OpenShift and Avi Objects“這個頁面 ( https://avinetworks.com/docs/ako/1.4/handling-objects/ ) 有更完整的討論。反正呢,這裡想讓大家知道的重點是:

  • 應用管理者使用Kubernetes標準的LoadBalancer Service / Ingress機制建立應用遞送要求。
  • 基於上述配置,AKO會自行要求Avi Controller建立對應的Virtual Service。
  • 各個對應Virtual Service使用的Virtual IP會在指定的VIP Pool範圍內自動配置。

先打住。這邊還有一個問題沒有說明:AVI內是怎麼做Ingress Host與IP間的管理維運呢?下一篇網誌來討論這個議題。

相关文章

评论

发表评论

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

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