全部產品
Search
文件中心

Container Service for Kubernetes:ALB配額計算方式

更新時間:Jan 10, 2025

配額(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自訂的轉寄條件的匹配評估數三者總和。當pathTypePrefix時,每條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 describekubectl get event命令,關注叢集中AlbConfig、Ingress、Service等資源的詳細資料及事件,即時瞭解調諧是否成功。

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

  1. 登入配額中心控制台

  2. 選擇以下任一方式進入建立配額警示入口。

    • 方式一:在通用配額產品列表頁面,在網路地區單擊應用型負載平衡ALB,進入通用配額列表頁面。

    • 方式二:在左側導覽列,單擊配額警示。在配額警示頁面,單擊建立配額警示。在通用配額列表頁面,選擇應用型負載平衡ALB

  3. 通用配額列表頁面,找到目標配額,在操作列單擊建立警示

  4. 警示規則建立頁面,設定警示規則,然後單擊確認

    表 1. 配額警示規則參數

    參數

    說明

    樣本

    規則名稱

    警示規則名稱。

    搶佔式的限購類執行個體vCPU數量上限警示規則

    警示指標

    配額警示的指標。取值:

    • 配額

    • 配額用量

    • 使用率(%)

    • 剩餘可用率(%)

    使用率(%)

    閾值及警示層級

    警示層級和該層級對應的閾值。

    警示層級對應的警示通知方式如下:

    • 緊急(Critical):郵件+警示回調。

    • 警告(Warn):郵件+警示回調。

    • 普通(Info):郵件+警示回調。

    您還需要選擇發送警示通知需要監控指標達到警示閾值的次數。取值:連續1個周期、連續3個周期、連續5個周期、連續10個周期、連續15個周期、連續30個周期、連續60個周期、連續70個周期、連續90個周期、連續120個周期和連續180個周期。

    您可以設定多級警示,當閾值處於不同區間時,對應不同警示層級,CloudMonitor通過不同渠道給您發送警示通知。

    • 警示層級:普通(Info),該警示層級對應的通知方式預設為郵件+警示回調

    • 閾值:>=80%。

    通道沉默周期

    警示發生後未恢複正常,間隔多久重複發送一次警示通知。取值:5分鐘、15分鐘、30分鐘、60分鐘、3小時、6小時、12小時和24小時。

    某監控指標達到警示閾值時發送警示,如果監控指標在通道沉默周期內持續超過警示閾值,在通道沉默周期內不會重複發送警示通知;如果監控指標在通道沉默周期後仍未恢複正常,則CloudMonitor再次發送警示通知。

    例如:當通道沉默周期選擇24小時時,如果警示未恢複正常,則間隔24小時後,CloudMonitor會再次發送警示通知。

    5分鐘

    生效時間

    警示規則的生效時間。警示規則僅在指定周期(星期一至星期日)的生效期內才會發送警示通知。

    • 周期:星期一~星期日

    • 時間:00:00~23:59

    警示連絡人群組

    發送警示的連絡人群組。

    應用分組的警示通知會發送給該警示連絡人群組中的警示連絡人。警示連絡人群組是一組警示連絡人,可以包含一個或多個警示連絡人。

    關於如何建立警示連絡人和警示連絡人群組,請參見建立警示連絡人或警示連絡人群組

    Elastic Compute Service規格配額管理員

    警示回調

    公網可訪問的URL,用於接收CloudMonitor通過POST請求推送的警示資訊。目前僅支援HTTP協議。

    當您需要測試警示回調地址的連通性時,可以執行以下操作。

    1. 單擊回調地址正後方的測試

      WebHook測試結果頁面,您可以通過Webhook返回的狀態代碼和測試結果詳情對警示回調地址的連通性進行判斷和排查。

      說明

      您還可以設定Webhook的語言,再次單擊測試,擷取對應的測試結果詳情。

    2. 單擊關閉

    http://alert.aliyun.com:8080/callback

    標籤

    警示規則的標籤。您最多可設定6組標籤。

    k1,v1

    推送渠道

    警示資訊的投遞渠道。取值:

    • Log Service

      如果您開啟Log Service開關,當警示發生時,會將警示資訊發送至Log Service的日誌庫。您需要設定Log Service的地區ProjectNameLogstore

      關於如何建立Project和Logstore,請參見快速入門

    • Message ServiceMNS-Topic

      如果您開啟Message ServiceMNS-Topic開關,當警示發生時,會將警示資訊發送至Simple Message Queue (formerly MNS)的主題。您需要設定Simple Message Queue (formerly MNS)的地區和主題。

      關於如何建立主題,請參見建立主題

    • Function Compute

      如果您開啟Function Compute開關,當警示發生時,會將警示通知發送至Function Compute進行格式處理。您需要設定Function Compute的地區、服務和函數。

      關於如何建立服務和函數,請參見快速建立函數

    關閉開關

    恢複通知

    是否在警示恢複時發送相應的恢複通知。預設開啟開關。

    開啟開關

    無資料處理方法

    無監控資料時警示的處理方式。取值:

    • 不做任何處理(預設值)

    • 發送無資料警示

    • 視為恢複

    不做任何處理

  5. 在左側導覽列,單擊配額警示,查看建立的配額警示資訊。

    您可以通過配額警示頁面,統一管理已建立的配額警示,如執行查看、修改、刪除配額警示操作。

  6. (可選)查看警示回調結果。

    如果您設定了警示回調,當警示回調成功時,您可以查看警示回調記錄和配額自動提升申請。

    1. 在左側導覽列,單擊警示歷史,查看警示回調記錄。

      當目標警示記錄的通知渠道中包括警示回調時,說明警示回調成功。

    2. 在左側導覽列,單擊申請歷史,查看配額自動提升申請。

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

  1. 登入負載平衡控制台的配額管理頁面

  2. 配額管理頁面,單擊應用型負載平衡ALB頁簽。

  3. 選擇配額類型通用配額,找到目標通用配額,在操作列單擊建立警示

  4. 警示規則建立頁面,設定警示規則,然後單擊確認

    表 1. 配額警示規則參數

    參數

    說明

    樣本

    規則名稱

    警示規則名稱。

    搶佔式的限購類執行個體vCPU數量上限警示規則

    警示指標

    配額警示的指標。取值:

    • 配額

    • 配額用量

    • 使用率(%)

    • 剩餘可用率(%)

    使用率(%)

    閾值及警示層級

    警示層級和該層級對應的閾值。

    警示層級對應的警示通知方式如下:

    • 緊急(Critical):郵件+警示回調。

    • 警告(Warn):郵件+警示回調。

    • 普通(Info):郵件+警示回調。

    您還需要選擇發送警示通知需要監控指標達到警示閾值的次數。取值:連續1個周期、連續3個周期、連續5個周期、連續10個周期、連續15個周期、連續30個周期、連續60個周期、連續70個周期、連續90個周期、連續120個周期和連續180個周期。

    您可以設定多級警示,當閾值處於不同區間時,對應不同警示層級,CloudMonitor通過不同渠道給您發送警示通知。

    • 警示層級:普通(Info),該警示層級對應的通知方式預設為郵件+警示回調

    • 閾值:>=80%。

    通道沉默周期

    警示發生後未恢複正常,間隔多久重複發送一次警示通知。取值:5分鐘、15分鐘、30分鐘、60分鐘、3小時、6小時、12小時和24小時。

    某監控指標達到警示閾值時發送警示,如果監控指標在通道沉默周期內持續超過警示閾值,在通道沉默周期內不會重複發送警示通知;如果監控指標在通道沉默周期後仍未恢複正常,則CloudMonitor再次發送警示通知。

    例如:當通道沉默周期選擇24小時時,如果警示未恢複正常,則間隔24小時後,CloudMonitor會再次發送警示通知。

    5分鐘

    生效時間

    警示規則的生效時間。警示規則僅在指定周期(星期一至星期日)的生效期內才會發送警示通知。

    • 周期:星期一~星期日

    • 時間:00:00~23:59

    警示連絡人群組

    發送警示的連絡人群組。

    應用分組的警示通知會發送給該警示連絡人群組中的警示連絡人。警示連絡人群組是一組警示連絡人,可以包含一個或多個警示連絡人。

    關於如何建立警示連絡人和警示連絡人群組,請參見建立警示連絡人或警示連絡人群組

    Elastic Compute Service規格配額管理員

    警示回調

    公網可訪問的URL,用於接收CloudMonitor通過POST請求推送的警示資訊。目前僅支援HTTP協議。

    當您需要測試警示回調地址的連通性時,可以執行以下操作。

    1. 單擊回調地址正後方的測試

      WebHook測試結果頁面,您可以通過Webhook返回的狀態代碼和測試結果詳情對警示回調地址的連通性進行判斷和排查。

      說明

      您還可以設定Webhook的語言,再次單擊測試,擷取對應的測試結果詳情。

    2. 單擊關閉

    http://alert.aliyun.com:8080/callback

    標籤

    警示規則的標籤。您最多可設定6組標籤。

    k1,v1

    推送渠道

    警示資訊的投遞渠道。取值:

    • Log Service

      如果您開啟Log Service開關,當警示發生時,會將警示資訊發送至Log Service的日誌庫。您需要設定Log Service的地區ProjectNameLogstore

      關於如何建立Project和Logstore,請參見快速入門

    • Message ServiceMNS-Topic

      如果您開啟Message ServiceMNS-Topic開關,當警示發生時,會將警示資訊發送至Simple Message Queue (formerly MNS)的主題。您需要設定Simple Message Queue (formerly MNS)的地區和主題。

      關於如何建立主題,請參見建立主題

    • Function Compute

      如果您開啟Function Compute開關,當警示發生時,會將警示通知發送至Function Compute進行格式處理。您需要設定Function Compute的地區、服務和函數。

      關於如何建立服務和函數,請參見快速建立函數

    關閉開關

    恢複通知

    是否在警示恢複時發送相應的恢複通知。預設開啟開關。

    開啟開關

    無資料處理方法

    無監控資料時警示的處理方式。取值:

    • 不做任何處理(預設值)

    • 發送無資料警示

    • 視為恢複

    不做任何處理

  5. 在目標配額項的操作列單擊image.png > 警示項

  6. 警示列表對話方塊中,可以查看建立的配額警示資訊。

相關文檔