ALB Ingress基於阿里雲應用型負載平衡ALB(Application Load Balancer)之上提供更為強大的Ingress流量管理方式,相容Nginx Ingress,具備處理複雜業務路由和認證自動探索的能力,支援HTTP、HTTPS和QUIC協議,滿足在雲原生應用情境下對超強彈性和大規模七層流量處理能力的需求。您可以參考本文在ACS叢集中部署服務並通過配置ALB Ingress實現Ingress流量管理。
ALB Ingress工作原理
ALB Ingress涉及到以下基本概念:
ALB Ingress Controller:負責管理Ingress資源的組件。它通過API Server動態地擷取Ingress資源和AlbConfig資源的變化,然後更新ALB執行個體。與Nginx Ingress Controller不同,ALB Ingress Controller 是 ALB 執行個體的控制面,負責管理 ALB 執行個體,但不直接處理使用者流量。使用者流量的轉寄由 ALB 執行個體來實現。ALB Ingress Controller會通過叢集API Server動態地擷取Ingress資源的變化,並依照Ingress所描述的轉寄規則動態地更新ALB執行個體。
AlbConfig(CRD):AlbConfig是由ALB Ingress Controller建立的一種CRD (Custom Resource Definition) 。AlbConfig中的參數決定了ALB執行個體的配置。一個AlbConfig對應一個ALB執行個體。ALB執行個體是使用者請求流量的入口,負責將使用者請求轉寄到後端Service中。它由應用型負載平衡ALB完全託管。相比起Nginx Ingress Controller,ALB Ingress免於營運,並且擁有更強大的彈性。
IngressClass:IngressClass定義了某一個Ingress與某一個AlbConfig的關聯。
Ingress:Ingress是Kubernetes中用於定義外部流量路由規則和訪問規則的資來源物件,ALB Ingress Controller通過監測Ingress資源的變化並更新ALB執行個體以實現流量轉寄。
Service:在Kubernetes中,Pod被認為是臨時資源,是不穩定而多變的。Service為具有相同功能的Pod提供了一個穩定、統一的入口。其他應用程式或服務可以通過訪問Service的虛擬IP和連接埠來與後端Pod進行通訊,而無需關注Pod可能發生的變化。
您可參照下圖,理解ALB執行個體與ALB Ingress之間的邏輯關係:
使用限制
AlbConfig、Namespace、Ingress和Service這些資源的名稱不能以aliyun開頭。
情境樣本
本教程以四個部署了Nginx的Pod為例,示範如何通過配置ALB Ingress,實現相同網域名稱不同URL路徑的流量轉寄。
前端請求 | 流量轉寄至 |
|
|
|
|
前提條件
步驟一:部署後端服務
使用控制台部署
登入容器計算服務控制台,在左側導覽列選擇叢集。
在叢集頁面,單擊目的地組群ID,然後在左側導覽列,選擇
。在無狀態頁面,單擊右上方的使用YAML建立資源。
進入建立頁面。
樣本模板:選擇自訂。
模板:輸入YAML設定檔代碼。該設定檔用於部署兩個名稱分別為
coffee
和tea
的Deployment,以及兩個名稱分別為coffee-svc
和tea-svc
的Service。
配置完成後單擊建立,頁面將提示建立成功。
檢查Deployment和Service建立成功:
在左側導覽列,選擇工作負載 > 無狀態。可以查看到名稱為coffee和tea的Deployment已部署。
在左側導覽列,選擇網路 > 服務。可查看到名稱為coffee-svc和tea-svc的Service已部署。
使用kubectl部署
使用以下內容建立cafe-service.yaml,用於部署兩個名稱分別為
coffee
和tea
的Deployment,以及兩個名稱分別為coffee-svc
和tea-svc
的Service。執行以下命令,部署兩個Deployment和兩個Service。
kubectl apply -f cafe-service.yaml
預期輸出:
deployment "coffee" created service "coffee-svc" created deployment "tea" created service "tea-svc" created
執行以下命令,查看應用和服務的狀態。
執行以下命令,查看應用的狀態。
kubectl get deployment
預期輸出:
NAME READY UP-TO-DATE AVAILABLE AGE coffee 2/2 2 2 2m26s tea 2/2 2 2 2m26s
執行以下命令,查看服務的狀態。
kubectl get svc
預期輸出:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE coffee-svc ClusterIP 172.16.XX.XX <none> 80/TCP 9m38s tea-svc ClusterIP 172.16.XX.XX <none> 80/TCP 9m38s
步驟二:建立ALBConfig
通過控制台建立ALBConfig
登入容器計算服務控制台,在左側導覽列選擇叢集。
在叢集頁面,單擊目的地組群ID,然後在左側導覽列,選擇工作負載 > 自訂資源。
單擊右上方使用YAML建立資源。
樣本模板:選擇自訂。
模板:輸入YAML設定檔代碼。
可調整參數說明如下:
參數
是否必填
說明
metadata.name
是
ALBConfig的名稱。
說明ALBConfig的名稱在叢集中必須是唯一的。因此,在建立ALBConfig時,您需要確保ALBConfig名稱的唯一性,以避免命名衝突。
spec.config.name
否
ALB執行個體的名稱。
spec.config.addressType
否
ALB執行個體的網路類型。取值如下:
Internet(預設值):公網類型。面向公網提供應用型負載平衡服務,公網可訪問。
說明應用型負載平衡通過綁定Elastic IP Address進行公網服務,使用公網類型ALB執行個體將收取Elastic IP Address的執行個體費與頻寬、流量費用,詳情參見隨用隨付。
Intranet:私網類型。面向VPC內部提供應用型負載平衡服務,公網不可訪問。
spec.config.zoneMappings
是
設定ALB交換器ID。建立交換器具體操作請參見建立和管理交換器。
說明指定的交換器必須在ALB當前所支援的可用性區域內,且與叢集處於同一VPC。關於ALB支援的地區與可用性區域,請參見ALB支援的地區與可用性區域。
應用型負載平衡支援多可用性區域部署,若當前地區支援2個及以上可用性區域,為保障業務高可用,請至少選擇2個或以上不同可用性區域的交換器。
spec.listeners
否
配置ALB的監聽連接埠和協議。本文配置樣本為連接埠80的HTTP監聽。
監聽定義了流量進入負載平衡的方式和規則,此處建議保留該配置,否則您需要另行建立監聽才可使用ALB Ingress。
配置完成後單擊建立,頁面將提示建立成功。
檢查ALB執行個體建立成功:
在頂部功能表列,選擇執行個體所屬的地區。
在執行個體頁面,可以在執行個體列表中查看到名稱為alb-test的ALB執行個體,表示執行個體建立成功。
通過kubectl建立ALBConfig
拷貝以下內容到alb-test.yaml檔案中,用於建立ALBConfig。
可調整參數說明如下:
參數
是否必填
說明
metadata.name
是
ALBConfig的名稱。
說明ALBConfig的名稱在叢集中必須是唯一的。因此,在建立ALBConfig時,您需要確保ALBConfig名稱的唯一性,以避免命名衝突。
spec.config.name
否
ALB執行個體的名稱。
spec.config.addressType
否
ALB執行個體的網路類型。取值如下:
Internet(預設值):公網類型。面向公網提供應用型負載平衡服務,公網可訪問。
說明應用型負載平衡通過綁定Elastic IP Address進行公網服務,使用公網類型ALB執行個體將收取Elastic IP Address的執行個體費與頻寬、流量費用,詳情參見隨用隨付。
Intranet:私網類型。面向VPC內部提供應用型負載平衡服務,公網不可訪問。
spec.config.zoneMappings
是
設定ALB交換器ID。建立交換器具體操作請參見建立和管理交換器。
說明指定的交換器必須在ALB當前所支援的可用性區域內,且與叢集處於同一VPC。關於ALB支援的地區與可用性區域,請參見ALB支援的地區與可用性區域。
應用型負載平衡支援多可用性區域部署,若當前地區支援2個及以上可用性區域,為保障業務高可用,請至少選擇2個或以上不同可用性區域的交換器。
spec.listeners
否
配置ALB的監聽連接埠和協議。本文的配置樣本為連接埠80的HTTP監聽。
監聽定義了流量進入負載平衡的方式和規則,此處建議保留該配置,否則您需要另行建立監聽才可使用ALB Ingress。
執行以下命令,建立ALBConfig。
kubectl apply -f alb-test.yaml
預期輸出:
albconfig.alibabacloud.com/alb-demo created
可以看到ALBConfig已經建立成功。
步驟三:建立IngressClass
IngressClass建議與ALBConfig一一對應。
通過控制台建立IngressClass
登入容器計算服務控制台,在左側導覽列選擇叢集。
在叢集頁面,單擊目的地組群ID,然後在左側導覽列,選擇工作負載 > 自訂資源。
單擊右上方使用YAML建立資源。
樣本模板:選擇自訂。
模板:輸入YAML設定檔代碼。
可調整參數說明如下:
參數
是否必填
說明
metadata.name
是
IngressClass的名稱。
說明IngressClass的名稱在叢集中必須是唯一的。因此,在建立IngressClass時,您需要確保IngressClass名稱的唯一性,以避免命名衝突。
spec.parameters.name
是
關聯的ALBConfig的名稱。
配置完成後單擊建立,頁面將提示建立成功。
檢查IngressClass建立成功:
在左側導覽列,選擇工作負載 > 自訂資源。
選擇資來源物件瀏覽器頁簽。
在API組搜尋欄中,輸入IngressClass進行搜尋,可查看到對應的IngressClass已建立。
通過kubectl建立IngressClass
建立並拷貝以下內容到alb.yaml檔案中,用於建立IngressClass。
可調整參數說明如下:
參數
是否必填
說明
metadata.name
是
IngressClass的名稱。
說明IngressClass的名稱在叢集中必須是唯一的。因此,在建立IngressClass時,您需要確保IngressClass名稱的唯一性,以避免命名衝突。
spec.parameters.name
是
關聯的ALBConfig的名稱。
執行以下命令,建立IngressClass。
kubectl apply -f alb.yaml
預期輸出:
ingressclass.networking.k8s.io/alb created
步驟四:建立Ingress
通過控制台建立Ingress
登入容器計算服務控制台,在左側導覽列選擇叢集。
在叢集列表頁面,單擊目的地組群名稱,然後在左側導覽列,選擇網路 > 路由。
在路由頁面,單擊建立 Ingress,在建立 Ingress對話方塊配置路由。
配置項
說明
樣本值
網關類型
可按需選擇ALB和MSE兩種應用負載平衡網關類型。
ALB應用負載平衡
名稱
自訂路由名稱。
cafe-ingress
Ingress Class
自訂Ingress的類。
alb
規則
單擊+ 添加規則可新增多個路由規則。
網域名稱:自訂網域名。
路徑映射:配置如下配置項。
路徑:指定服務訪問的URL路徑。本例中不做配置,保留根路徑/。
匹配規則:支援首碼匹配(Prefix)、完整匹配(Exact)和預設(ImplementationSpecific)。
服務名稱:選擇目標服務,即K8s內的Service。
連接埠:選擇服務需要暴露的連接埠。
Ingress支援同一個網域名稱下配置多條路徑。單擊+ 添加路徑新增路徑。
網域名稱:demo.domain.ingress.top
路徑映射:
路徑:/tea
匹配規則:預設(ImplementationSpecific)
服務名稱:tea-svc
連接埠:80
路徑映射:
路徑:/coffee
匹配規則:預設(ImplementationSpecific)
服務名稱:coffee-svc
連接埠:80
TLS配置
開啟TLS配置開關,配置安全的路由服務。
網域名稱:自訂網域名。
保密字典:根據需要選擇對應的保密字典。
如果您需要建立Secret,請執行如下操作。
在保密字典右側,單擊建立。
在建立 Secret對話方塊,自訂保密字典的名稱、Cert、Key,然後單擊確定。
在保密字典的下拉框,選擇已建立的Secret。
單擊+ 新增TLS配置,可配置多條TLS。
更多詳情,請參見配置HTTPS認證以實現加密通訊。
關閉TLS配置,此樣本中不需要配置TLS。
更多配置
灰階發布:開啟灰階發布開關。灰階規則可按照要求標頭、Cookie 、權重三個維度進行設定。
說明要求標頭、Cookie 、權重可以只設定一種,若同時設定生效規則按要求標頭、Cookie、權重順序匹配。
按要求標頭:基於Request Header的流量切分,設定後會添加註解
nginx.ingress.kubernetes.io/canary-by-header
、nginx.ingress.kubernetes.io/canary-by-header-value
或nginx.ingress.kubernetes.io/canary-by-header-pattern
。按Cookie:基於Cookie的流量切分,設定後會添加註解
nginx.ingress.kubernetes.io/canary-by-cookie
。按權重:佈建要求到指定服務的百分比(值為0~100的整數),設定後會添加註解
nginx.ingress.kubernetes.io/canary-weight
。
協議:指定後端服務的協議,設定後會添加註解
nginx.ingress.kubernetes.io/backend-protocol
。支援HTTP、HTTPS、gRPC、gRPCS四種服務合約。
重寫路徑:將用戶端請求中的路徑重寫後發送到後端服務,設定後會添加註解
nginx.ingress.kubernetes.io/rewrite-target
。
關閉灰階發布,協議和重寫路徑保持預設。此樣本中不需要配置灰階發布、協議、重新路徑。
自訂轉寄規則
開啟自訂轉寄規則,可精細化管理入站流量。
說明轉寄規則的條件條目上限為10個。
在轉寄條件下拉框中選擇:
網域名稱:
匹配請求網域名稱,如果設定了多個網域名稱,則網域名稱之間是或的關係。設定後會添加註釋
alb.ingress.kubernetes.io/conditions.host-example
。路徑:
匹配請求路徑,如果設定了多個路徑,則路徑之間是或的關係。設定後會添加註釋
alb.ingress.kubernetes.io/conditions.path-example
。HTTP標題:
以索引值對形式匹配請求的頭部資訊。例如,鍵是:
headername
值是:headervalue1
。如果設定了多個Header值,則Header之間是或的關係。設定後會添加註釋alb.ingress.kubernetes.io/conditions.http-header-example
。
在轉寄動作下拉框中選擇:
轉寄至
轉寄到後端多伺服器組。在服務名稱中,請選擇目標服務。在連接埠中,選擇目標連接埠號碼。然後自訂配置權重值。
說明選擇轉寄至,就不需要配置規則中的路徑映射。
返回固定響應
設定通過ALB給用戶端返回固定響應內容,可以設定響應狀態代碼,本文內容和本文類型。按需求配置響應狀態代碼,響應本文類型(可選)、響應本文(可選)。
響應本文類型:
text/plain:表示無格式的內容類型。
text/css:表示XML格式的內容。
text/html:表示HTML格式的內容。
application/javascript:表示JavaScript格式的內容。
application/json:表示JSON格式內容類型。
自訂轉寄規則支援多種轉寄條件及轉寄動作,您可以佈建網域名、路徑、HTTP標題轉寄條件,轉寄至、返回固定響應的轉寄動作。瞭解更多配置,請參見自訂ALB Ingress的轉寄規則。
關閉自訂轉寄規則。此樣本中不需要配置自訂轉寄規則。
註解
您可自訂註解名稱和值,也可根據名稱選擇或搜尋要配置的註解。Ingress的註解請參見Annotations。
單擊+添加註解,可對Ingress無上限地添加註解。
無需配置,此樣本不需要配置註解。
標籤
標籤的作用是為Ingress添加對應的標籤,標示該Ingress的特點。
單擊+添加標籤,可對Ingress無上限地添加標籤。
無需配置,此樣本不需要配置標籤。
配置完成,在建立Ingress頁面的左下角,單擊確定。
檢查Ingress建立成功:
在左側導覽列,選擇網路 > 路由。可查看到名稱為cafe-ingress的Ingress已部署。
在cafe-ingress的端點列,可查看到端點資訊。
通過kubectl建立Ingress
建立並拷貝以下內容到cafe-ingress.yaml檔案中,用於建立Ingress。
可調整參數說明如下:
參數
是否必填
說明
metadata.name
是
Ingress的名稱。
說明Ingress的名稱在叢集中必須是唯一的。因此,在建立Ingress時,您需要確保Ingress名稱的唯一性,以避免命名衝突。
spec.ingressClassName
是
關聯的IngressClass的名稱。
spec.rules.host
否
HTTP頭部host欄位網域名稱資訊,需要配置為您的自有網域名稱。
當您在瀏覽器中訪問您的自有網域名稱時,例如“http://demo.domain.ingress.top”,瀏覽器會在發送HTTP請求時自動添加一個“Host: demo.domain.ingress.top”的頭部欄位。這樣,伺服器就可以根據該頭部欄位來識別請求的目標主機名稱。在Kubernetes中,Ingress規則中的host欄位會與來自請求的Host頭部欄位進行匹配。當匹配成功時,Ingress規則就會將請求路由到相應的後端服務進行處理。
說明此處如果配置了自有網域名稱,需要確保該自有網域名稱完成備案,否則可能訪問時無法解析。具體操作,請參見ICP備案流程。
此處如果未配置,那麼該Ingress規則將匹配所有到達Ingress Controller的請求。
spec.rules.http.paths.path
是
轉寄路徑URL。
spec.rules.http.paths.pathType
是
URL匹配規則。詳情可參考基於URL路徑轉寄請求。
spec.rules.http.paths.backend.service.name
是
填寫您此前建立的Service名稱。
spec.rules.http.paths.backend.service.port.number
是
填寫您此前建立的Service的服務連接埠號碼。
這個連接埠號碼的設定非常重要,因為它決定了在路由到後端服務時使用的連接埠。確保連接埠號碼正確設定,以確保請求可以正確路由到後端服務並被處理。
執行以下命令,配置
coffee
和tea
服務對外暴露的網域名稱和path
路徑。kubectl apply -f cafe-ingress.yaml
預期輸出:
ingress.networking.k8s.io/cafe-ingress created
(可選)執行以下命令擷取ALB執行個體DNS地址。
kubectl get ingress
預期輸出:
NAME CLASS HOSTS ADDRESS PORTS AGE cafe-ingress alb demo.domain.ingress.top alb-m551oo2zn63yov****.cn-hangzhou.alb.aliyuncs.com 80 50s
(可選)步驟五:佈建網域名解析
如果您在建立Ingress時配置了spec.rules.host
欄位為您的自有網域名稱,您需要將您的網域名稱添加CNAME記錄解析到ALB DNS名稱。後續通過你的自有網域名稱訪問服務。
登入容器計算服務控制台。
單擊叢集名稱,進入叢集管理頁面。
在左側導覽列,選擇網路 > 路由。
在cafe-ingress的端點列,複製其對應的DNS名稱。
完成以下步驟來添加CNAME解析記錄。
登入網域名稱解析控制台。
在網域名稱解析頁面單擊添加網域名稱。
在添加網域名稱對話方塊中輸入您的主機網域名稱,然後單擊確認。
重要您的主機網域名稱需已完成TXT記錄驗證。
在目標網域名稱的操作列單擊解析設定。
在解析設定頁面單擊添加記錄。
在添加記錄面板配置以下資訊完成CNAME解析配置,然後單擊確認。
配置
說明
記錄類型
在下拉式清單中選擇CNAME。
主機記錄
您的網域名稱的首碼,例如
www
。解析請求來源
選擇預設。
記錄值
輸入欄位名對應的CNAME地址,即您複製的DNS名稱。
TTL
全稱Time To Live,表示DNS記錄在DNS伺服器上的緩衝時間,本文使用預設值。
步驟六:測試流量轉寄
在瀏覽器中輸入“測試網域名稱+URL路徑”,測試流量轉寄是否正確。
如果您配置了自有網域名稱,則“測試網域名稱”為您的自有網域名稱。
如果您未配置自有網域名稱,則“測試網域名稱”為cafe-ingress的端點DNS名稱。
測試網域名稱以demo.domain.ingress.top
為例:
在瀏覽器中輸入
demo.domain.ingress.top/coffee
,將返回coffee-svc對應的後端服務介面。在瀏覽器中輸入
demo.domain.ingress.top/tea
,將返回tea-svc對應的後端服務介面。
相關文檔
如需瞭解ALB Ingress服務的進階用法,例如如何將來自不同網域名稱或URL路徑的請求轉寄給不同的後端伺服器組、配置健全狀態檢查、將HTTP訪問重新導向至HTTPS、灰階發布、配置自訂監聽連接埠等,請參見ALB Ingress服務進階用法。
如需自訂ALB Ingress的轉寄規則,請自行配置轉寄條件和動作,請參見自訂ALB Ingress的轉寄規則。
如需讓HTTPS監聽轉寄來自HTTPS協議的請求,請參見配置HTTPS認證以實現加密通訊。
如果您在使用ALB Ingress過程中遇到問題,可先參見ALB Ingress異常問題排查、ALB Ingress FAQ自助排查問題。