ALB的配額計算方式有哪些 -

配額（Quota）是指在特定時間段內，對某個資源或服務的使用量或訪問次數的限制，通常用於控制資源的分配和使用。在阿里雲負載平衡（ALB）服務中，配額計算方式是根據不同的資源類型和資源使用方式來確定的。本文從標準版ALB執行個體、伺服器組、監聽和轉寄規則幾個方面介紹ALB的配額計算方式。

ALB配額計算樣本情境

ALB執行個體通過Ingress資源來管理和路由來自外部的請求。Ingress定義了路由規則，將請求轉寄到相應的後端伺服器組（Service:Port）。後端服務由多個Pod組成的集合，負責處理來自ALB執行個體的請求。這樣ALB執行個體、Ingress、Service:Port和Pod之間形成了一種映射關係，實現了請求的轉寄和負載平衡。

針對上圖中涉及到的配額計算方式，下文將從標準版ALB執行個體、伺服器組、監聽和轉寄規則幾個方面進行說明。

標準版ALB執行個體配額

資源	配額名稱	計算方式	情境說明（見上圖）
一個ALB執行個體可添加的擴充認證數（不計入預設認證）	alb_quota_loadbalancer_certificates_num_standard_edition	一個ALB執行個體添加的擴充認證數是該執行個體下每個監聽添加的擴充認證數的總和。 ALB Ingress可添加的擴充認證數，會根據認證管理方式的不同有如下計算方式：自動探索認證數：根據該網域名稱在阿里雲數位憑證中心對應的認證總數來計算。 Secret認證數：根據`spec.tls`下的`secretName`的總數來計算。同一命名空間的Secret認證數不重複計算，不同命名空間的認證數疊加計算。通過ALBConfig指定認證數：根據AlbConfig中的CertificateId數量來計算。認證混合使用時：根據認證管理方式的相容性計算認證總數。如果一個ALB Ingress被關聯至多個監聽，則該認證數將在每個監聽下都被計算一次。	ALB Ingress 1監聽協議為HTTP，HTTP協議無需使用擴充認證，因此擴充認證數為0。 ALB Ingress 2監聽協議為HTTP，由於HTTP協議無需使用擴充認證，因此擴充認證數為0。 ALB Ingress 3被關聯至監聽3和監聽4，監聽3擴充認證數為1，監聽4擴充認證數為1，因此ALB Ingress 3添加的擴充認證數為2。
一個ALB執行個體可添加的轉寄規則數（不計入預設規則）	alb_quota_loadbalancer_rules_num_standard_edition	一個ALB執行個體添加的轉寄規則數為該執行個體下每個監聽中所有ALB Ingress的轉寄規則數之和。 ALB Ingress添加的轉寄規則數的計算方式為：該ALB Ingress中`spec.rules`欄位下所有`host`配置項下的`path`列表條目數之和。若該ALB Ingress被關聯至多個監聽，則其轉寄規則數在每個監聽下都將被記入一次。	ALB Ingress 1轉寄規則數為1。 ALB Ingress 2轉寄規則數為1。 ALB Ingress 3配置1條轉寄規則，但同時被關聯至監聽3和監聽4，因此ALB Ingress3添加的轉寄規則數為2。
一個ALB執行個體可添加的後端伺服器數	alb_quota_loadbalancer_servers_num_standard_edition	一個ALB執行個體添加的後端伺服器數為該執行個體下每個監聽中所有ALB Ingress的後端伺服器數之和。 ALB Ingress添加的後端伺服器數的計算方式為：該ALB Ingress下每條轉寄規則的後端Service的Pod數之和。若該ALB Ingress被關聯至多個監聽，則其後端伺服器數在每個監聽下都將被計入一次。	ALB Ingress 1添加的後端伺服器數為3。 ALB Ingress 2添加的後端伺服器數為3。 ALB Ingress 3配置1條轉寄規則，且同時被關聯至監聽3和監聽4，其後端Service的Pod數為2，因此ALB Ingress3添加的後端伺服器數為4。
一個ALB執行個體可添加的監聽數	alb_quota_loadbalancer_listeners_num_standard_edition	一個ALB執行個體添加的監聽數為AlbConfig中Listeners列表所包含的`port:protocol`組合數。每個ALB Ingress關聯的監聽數由註解項`alb.ingress.kubernetes.io/listen-ports`的值決定。	ALB Ingress 1關聯的監聽數為1。 ALB Ingress 2關聯的監聽數為1。 ALB Ingress 3關聯的監聽數為2。

伺服器組配額

資源	配額名稱	計算方式	情境說明（見上圖）
同一個後端伺服器（IP）可被添加到ALB後端伺服器組的次數	alb_quota_server_added_num	一個Pod IP被添加到一個Service:Port組合中，而該Service:Port組合又被多個轉寄規則關聯時，每個關聯的轉寄規則都會計算為一個計數。如果這些轉寄規則又被關聯到多個監聽，那麼在每個監聽下都會計數一次。	Pod1被添加到Service1:Port80與Service2:Port80，二者各與1條轉寄規則相關聯，因此Pod1被添加到ALB後端伺服器組的次數為2。Pod2與Pod3同理。 Pod4被添加到Service3:Port80，與1條轉寄規則相關聯，該轉寄規則被關聯至2個監聽，因此Pod4被添加到ALB後端伺服器組的次數為2。Pod5同理。
同一個伺服器組可被關聯ALB監聽和轉寄規則的次數	alb_quota_servergroup_attached_num	一個Service:Port組合所關聯的轉寄規則數。若轉寄規則被關聯至多個監聽，則在每個監聽下都將被計數一次。	Service1:Port80關聯1條轉寄規則，該轉寄規則被關聯至1個監聽，因此Service1:Port80被關聯至ALB監聽和轉寄規則的次數為1。Service2:Port80同理。 Service3:Port80關聯1條轉寄規則，該轉寄規則被關聯至2個監聽，因此Service3:Port80被關聯至ALB監聽和轉寄規則的次數為2。
一個伺服器組可添加的後端伺服器數（IP和連接埠）	alb_quota_servergroup_servers_num	ALB Ingress的一個Service:Port組合所添加的Pod:Port的組合數。	Service1:Port80共有3個Pod，因此Service1:Port80添加的後端伺服器數為3。Service2:Port80同理。 Service3:Port80共有2個Pod，因此Service3:Port80添加的後端伺服器數為2。

監聽配額

資源

配額名稱

計算方式

情境說明（見上圖）

一個監聽可關聯的存取控制數

AlbConfig中Listeners列表裡

每個port:protocol對應的非空的aclConfig數。

監聽1關聯的存取控制數為1。
監聽2關聯的存取控制數為1。
監聽3關聯的存取控制數為0。
監聽4關聯的存取控制數為0。

一個監聽可關聯的存取控制條目數

AlbConfig中Listeners列表裡

每個port:protocol對應的非空的aclConfig包含的ACL條目數之和。

監聽1關聯的存取控制條目數為該aclId對應的存取控制條目數。
監聽2關聯的存取控制條目數為2。
監聽3關聯的存取控制條目數為0。
監聽4關聯的存取控制條目數為0。

轉寄規則配額

資源	配額名稱	計算方式	情境說明（見上圖）
一條轉寄規則可添加的動作數	--	建立或更新轉寄規則時，若該轉寄規則後端servicePort的名稱為`use-annotation`，則動作數為後端服務通過Annotation自訂的轉寄動作數的總和。建立或更新轉寄規則時，若該轉寄規則後端servicePort的名稱不是`use-annotation`，則動作數為後端服務通過Annotation自訂的轉寄動作數加上1。	ALB Ingress 1定義了1條轉寄規則，該轉寄規則後端servicePort為80，未通過Annotation自訂的轉寄動作，因此該轉寄規則添加的動作數為1。 ALB Ingress 2與ALB Ingress 3同理，各定義了1條轉寄規則。
一條轉寄規則可添加的匹配評估數	alb_quota_rule_matchevaluations_num	建立或更新轉寄規則時，該轉寄規則的非空Host數、Path匹配評估數、後端服務通過Annotation自訂的轉寄條件的匹配評估數三者總和。當`pathType`為`Prefix`時，每條Path的匹配評估數為2，`pathType`為其他值時，每條Path的匹配評估數為1。	ALB Ingress 1定義了1條轉寄規則，該轉寄規則非空Host數為1，Path數為1，後端服務通過annotation自訂的轉寄條件的匹配評估數為1，因此該轉寄規則添加的匹配評估數為3。 ALB Ingress 2定義了1條轉寄規則，該轉寄規則的非空Host數為1，Path數為1，因此該轉寄規則添加的匹配評估數為2，ALB Ingress 3定義的1條轉寄規則同理。
一條轉寄規則可添加的萬用字元數	-	建立或更新轉寄規則時，該轉寄規則的動作和匹配評估所包含的萬用字元總數。	ALB Ingress 2定義了1條轉寄規則，該轉寄規則關於Host的匹配評估中包含一個萬用字元*，因此該轉寄規則添加的萬用字元數為1。

建立配額警示

ALB的部分配額項支援設定預警，可設定配額使用量或剩餘可用量的閾值。當達到預設閾值時，系統會通過HTTP協議的POST請求向預設的回調地址發送警示資訊。通過建立配額警示，您可以在配額不足時及時申請提升配額，從而避免因超限引起的調諧失敗，導致轉寄規則或後端節點無法成功掛載到ALB上。同時，您也可以使用kubectl describe及kubectl get event命令，關注叢集中AlbConfig、Ingress、Service等資源的詳細資料及事件，即時瞭解調諧是否成功。

通過配額中心建立配額警示

登入配額中心控制台。
選擇以下任一方式進入建立配額警示入口。
- 方式一：在通用配額產品列表頁面，在網路地區單擊應用型負載平衡ALB，進入通用配額列表頁面。
- 方式二：在左側導覽列，單擊配額警示。在配額警示頁面，單擊建立配額警示。在通用配額列表頁面，選擇應用型負載平衡ALB。
在通用配額列表頁面，找到目標配額，在操作列單擊建立警示。

在建立配額警示面板，設定配額警示相關參數，然後單擊確定。

參數	說明
規則名稱	配額警示的規則名稱。
警示指標	配額警示的指標。包括：用量、使用率（%）、剩餘可用量和剩餘可用率（%）。
配額警示閾值	配額警示的閾值。您需要根據警示指標設定配額警示的閾值。當警示指標選擇用量時，如果配額的使用量大於等於閾值，當前阿里雲帳號會收到警示通知。當警示指標選擇使用率（%）時，如果配額的使用率大於等於閾值，當前阿里雲帳號會收到警示通知。取值範圍：[50%, 100%]。當警示指標選擇剩餘可用量時，如果配額的剩餘可用量小於等於閾值，當前阿里雲帳號會收到警示通知。當警示指標選擇剩餘可用率（%）時，如果配額的剩餘可用率小於等於閾值，當前阿里雲帳號會收到警示通知。取值範圍：（0%, 50%]。
警示回調	配額中心將警示資訊通過HTTP協議的POST請求發送到您指定的公網URL地址。警示回調的請求樣本和參數說明，請參見警示回調的請求內容是什嗎？。說明配額中心的警示精度預設為15分鐘，表示配額中心會在配額達到警示閾值後的大約15分鐘後發送警示通知。當您的警示回調採用與DingTalk機器人的Webhook方式整合時，必須先設定DingTalk機器人的自訂關鍵字為警示，再複製Webhook地址作為警示回調的URL地址。

在左側導覽列，單擊配額警示，查看建立的配額警示資訊。
您可以通過配額警示頁面，統一管理已建立的配額警示，如執行查看、修改、刪除配額警示操作。
（可選）查看警示回調結果。
如果您設定了警示回調，當警示回調成功時，您可以查看警示回調記錄和配額自動提升申請。
1. 在左側導覽列，單擊警示歷史，查看警示回調記錄。
  當目標警示記錄的通知渠道中包括警示回調時，說明警示回調成功。
2. 在左側導覽列，單擊申請歷史，查看配額自動提升申請。

通過負載平衡控制台建立配額警示

登入負載平衡控制台的配額管理頁面。
在配額管理頁面，單擊應用型負載平衡ALB頁簽。
選擇配額類型為通用配額，找到目標通用配額，在操作列單擊建立警示。