All Products
Search
Document Center

Container Service for Kubernetes:Methods to calculate ALB quotas

Last Updated:Feb 07, 2025

A quota sets the maximum usage of a resource or the maximum QPS of a service within a time period. Quotas are commonly used to manage resource allocation and consumption. The method to calculate an Application Load Balancer (ALB) quota varies based on the resource type and resource usage. This topic describes the methods to calculate the ALB quotas related to standard ALB instances, backend server groups, listeners, and forwarding rules.

Scenario (see the preceding figure)

ALB instances use Ingresses to manage and forward external requests. Ingresses define rules that are used to forward requests to backend server groups (Service:port pairs). Then, the requests are sent to and processed by backend applications, which run in a group of pods. The mappings between ALB instances, Ingresses, backend server groups (Service:port pairs), and pods together comprise a routing system for request forwarding and load balancing.

image

The following table describes the methods to calculate the ALB quotas related to standard ALB instances, backend server groups, listeners, and forwarding rules.

ALB quotas related to standard ALB instances

Quota description

Name/ID

Calculation method

Scenario (see the preceding figure)

Maximum number of additional certificates that can be added to an ALB instance (excluding default certificates)

alb_quota_loadbalancer_certificates_num_standard_edition

The maximum number of additional certificates that can be added to an ALB instance equals the total number of additional certificates that can be added to all listeners of the ALB instance.

The number of additional certificates that can be added to an ALB Ingress varies based on how the certificates are configured:

  • If automatic certificate discovery is configured, the number of additional certificates that can be added to the ALB Ingress equals the total number of certificates associated with the domain name in the Certificate Management Service console.

  • If certificates are managed as Kubernetes Secrets, the number of additional certificates that can be added to the ALB Ingress equals the number of Secrets listed in the secretName field of the spec.tls parameter. Certificates managed as Secrets in all namespaces are subject to the calculation. However, the certificates managed as Secrets in the same namespace are counted only once.

  • If certificates are specified in an AlbConfig, the number of additional certificates that can be added to the ALB Ingress equals the number of certificates listed in the CertificateId field of the AlbConfig.

  • If more than one of the preceding methods is used to configure certificates at the same time, the number of additional certificates that can be added to an ALB Ingress depends on the compatibility between the methods that are used.

  • If the ALB Ingress is associated with multiple listeners, the certificates that are configured for the ALB Ingress are counted multiple times based on the number of listeners.

  • ALB Ingress 1 is associated with an HTTP listener. HTTP does not require additional certificates. In this case, the number of additional certificates that can be added to ALB Ingress 1 is zero.

  • ALB Ingress 2 is associated with an HTTP listener. HTTP does not require additional certificates. In this case, the number of additional certificates that can be added to ALB Ingress 2 is zero.

  • ALB Ingress 3 is associated with HTTPS Listener 3 and HTTPS Listener 4. The number of additional certificates added to HTTPS Listener 3 is one and that for HTTP Listener 4 is also one. In this case, the number of additional certificates that can be added to ALB Ingress 3 is two.

Maximum number of forwarding rules that can be configured for an ALB instance (excluding default forwarding rules)

alb_quota_loadbalancer_rules_num_standard_edition

The maximum number of forwarding rules that can be configured for an ALB instance equals the total number of forwarding rules of the ALB Ingresses associated with all listeners of the ALB instance.

The number of forwarding rules of an ALB Ingress equals the number of entries listed in the path field of the host parameter in the spec.rules section of the ALB Ingress configuration file. If the ALB Ingress is associated with multiple listeners, the forwarding rules of the ALB Ingress are counted multiple times based on the number of listeners.

  • ALB Ingress 1 has one forwarding rule.

  • ALB Ingress 2 has one forwarding rule.

  • ALB Ingress 3 has one forwarding rule and is associated with Listener 3 and Listener 4. In this case, the number of forwarding rules of ALB Ingress 3 is two.

Maximum number of backend servers that can be added to an ALB instance

alb_quota_loadbalancer_servers_num_standard_edition

The maximum number of backend servers that can be added to an ALB instance equals the total number of backend servers of the ALB Ingresses associated with all listeners of the ALB instance.

The number of backend servers of an ALB Ingress equals the total number of the backend pods specified in all forwarding rules of the ALB Ingress. If the ALB Ingress is associated with multiple listeners, the backend pods of the ALB Ingress are counted multiple times based on the number of listeners.

  • ALB Ingress 1 has three backend pods.

  • ALB Ingress 2 has three backend pods.

  • ALB Ingress 3 has one forwarding rule and two backend pods, and is associated with Listener 3 and Listener 4. In this case, the number of backend pods of ALB Ingress 3 is four.

Maximum number of listeners that can be added to an ALB instance

alb_quota_loadbalancer_listeners_num_standard_edition

The number of listeners that are added to an ALB instance equals the number of port:protocol pairs listed in the Listeners parameter of the AlbConfig used to configure the ALB instance.

The number of listeners that are associated with an ALB Ingress depends on the value of the alb.ingress.kubernetes.io/listen-ports annotation in the ALB Ingress configuration.

  • ALB Ingress 1 is associated with one listener.

  • ALB Ingress 2 is associated with one listener.

  • ALB Ingress 3 is associated with two listeners.

Quotas related to server groups

Quota description

Name/ID

Calculation method

Scenario (see the preceding figure)

Maximum number of ALB server groups in which a backend server (IP address) can be specified

alb_quota_server_added_num

If a pod IP address is specified as the backend server of a Service:port pair and the Service:port pair is specified in multiple forwarding rules, the pod IP address is counted multiple times based on the number of forwarding rules. In this case, if each of the preceding forwarding rules is associated with multiple listeners, the pod IP address is also counted multiple times based on the number of listeners.

  • Pod 1 is specified as a backend server of Service 1:port 80 and Service 2:port 80. Service 1:port 80 and Service 2:port 80 each are associated with a separate forwarding rule. In this case, the number of ALB backend server groups in which Pod 1 is specified is two. Similarly, the number of ALB backend server groups in which Pod 2 is specified is two, and that for Pod 3 is also two.

  • Pod 4 is specified as a backend server of Service 3:port 80 and Service 3:port 80 is specified in a forwarding rule that is associated with two listeners. In this case, the number of ALB backend server groups in which Pod 4 is specified is two. Similarly, the number of ALB backend server groups in which Pod 5 is specified is two.

Maximum number of times that an ALB server group can be associated with listeners and forwarding rules

alb_quota_servergroup_attached_num

The maximum number of times that an ALB server group (Service:port pair) can be associated with listeners and forwarding rules depends on the forwarding rules in which the ALB server group (Service:port pair) is specified.

If a forwarding rule in which the ALB server group (Service:port pair) is specified is associated with multiple listeners, the ALB server group (Service:port pair) is counted multiple times based on the number of listeners.

  • Service 1:port 80 is specified in one forwarding rule and the forwarding rule is associated with one listener. In this case, the number of times that Service 1:port 80 is associated with listeners and forwarding rules is one. Similarly, the number of times that Service 2:port 80 is associated with listeners and forwarding rules is one.

  • Service 3:port 80 is specified in one forwarding rule and the forwarding rule is associated with two listeners. In this case, the number of times that Service 3:port 80 is associated with listeners and forwarding rules is two.

Maximum number of backend servers (IP addresses and ports) that can be added to a server group (Service:port pair)

alb_quota_servergroup_servers_num

The maximum number of backend servers (IP addresses and ports) that can be added to a server group equals the number of pod:port pairs of the server group (Service:port pair).

  • Service 1:port 80 has three backend pods. In this case, the number of backend servers added to Service 1:port 80 is three. Similarly, the number of backend servers added to Service 2:port 80 is three.

  • Service 3:port 80 has two backend pods. In this case, the number of backend servers added to Service 3:port 80 is two.

Quotas related to listeners

Quota description

Name/ID

Calculation method

Scenario (see the preceding figure)

Maximum number of network access control lists (ACLs) that can be associated with a listener

-

The maximum number of network ACLs that can be associated with a listener depends on the total number of entries in the non-empty aclConfig fields of all port:protocol pairs in the Listeners parameter of the AlbConfig.

  • Listener 1 is associated with one network ACL.

  • Listener 2 is associated with one network ACL.

  • Listener 3 is associated with zero network ACL.

  • Listener 4 is associated with zero network ACLs.

Maximum number of network ACL entries that can be associated with a listener

-

The maximum number of network ACL entries that can be associated with a listener depends on the total number of entries in the non-empty aclConfig fields of all port:protocol pairs in the Listeners parameter of the AlbConfig.

  • The number of network ACLs associated with Listener 1 depends on the number of network ACLs specified in the aclId field.

  • Listener 2 is associated with two network ACLs.

  • Listener 3 is associated with zero network ACLs.

  • Listener 4 is associated with zero network ACLs.

Quotas related to forwarding rules

Quota description

Name/ID

Calculation method

Scenario (see the preceding figure)

Maximum number of actions that can be specified in a forwarding rule

--​

  • When you create or update a forwarding rule, if you set the servicePort field to use-annotation, the maximum number of actions that can be specified in the forwarding rule equals the total number of custom actions specified by using annotations.

  • When you create or update a forwarding rule, if you set the servicePort field to a value other than use-annotation, the maximum number of actions that can be specified in the forwarding rule equals the total number of custom actions specified by using annotations plus 1.

  • ALB Ingress 1 has one forwarding rule in which the backend Service port is 80 and no custom actions are specified by using annotations. In this case, the maximum number of actions that can be specified in the forwarding rule of ALB Ingress 1 is one.

  • Similarly, ALB Ingress 2 and ALB Ingress 3 each have one forwarding rule.

Maximum number of match conditions that can be specified in a forwarding rule

alb_quota_rule_matchevaluations_num

When you create or update a forwarding rule, the maximum number of match conditions that can be specified in the forwarding rule equals the sum of the number of non-empty hosts in the forwarding rule, the number of path match conditions, and the number of match conditions for the custom forwarding conditions specified by using annotations. If you set pathType to Prefix, the number of match conditions for each path is two. If you set pathType to other values, the number of match conditions for each path is one.

  • ALB Ingress 1 has one forwarding rule, the number of non-empty hosts in the forwarding rule is one, the number of paths is one, and the number of match conditions for the custom forwarding conditions specified by using annotations is one. In this case, the maximum number of match conditions that can be specified in the forwarding rule is three.

  • ALB Ingress 2 has one forwarding rule, the number of non-empty hosts in the forwarding rule is one, and the number of paths is one. In this case, the maximum number of match conditions that can be specified in the forwarding rule is two. Similarly, the maximum number of match conditions that can be specified in the forwarding rule of ALB Ingress 3 is two.

Maximum number of wildcard characters that can be used in a forwarding rule

-

When you create or update a forwarding rule, the maximum number of wildcard characters that can be used in the forwarding rule equals the total number of wildcard characters contained in the actions and match conditions specified in the forwarding rule.

ALB Ingress 2 has one forwarding rule and the host match condition in the forwarding rule has only one wildcard character, which is an asterisk (*). In this case, the maximum number of wildcard characters that can be used in the forwarding rule is one.

Create an alert rule for a quota item

You can create alert rules for some quota items by specifying a threshold for quota usage or available quota. If the usage of a quota reaches the specified threshold, the system sends an alert notification to the callback URL that you specified in the alert rule through an HTTP POST request. We recommend that you take the alerts into consideration and apply for a quota increase in advance to avoid reconciliation failures due to quota exceedance. Such failures can result in forwarding rules or backend nodes failing to mount to the ALB. Additionally, you can monitor the status of reconciliation by using the kubectl describe and kubectl get event commands to view details and events related to resources such as AlbConfig, Ingresses, and Services in the cluster.

Procedure (Quota Center)

  1. Log on to the Quota Center console.

  2. Use one of the following methods to create an alert rule:

    • Method 1: On the Products with General Quotas page, click Application Load Balancer in the Networking section, and then click the General Quota tab.

    • Method 2: In the left-side navigation pane, click Quota Alerts. On the Quota Alerts page, click Create Quota Alert Rule. On the General Quotas page, select Application Load Balancer from the Product Name drop-down list.

  3. On the General Quotas page, find the quota that you want to manage and click Create Alert Rule in the Actions column.

  4. On the Create Alarm Rule page, configure the parameters and click Confirm.

    Table 1 Parameters for creating an alert rule for a quota item

    Parameter

    Description

    Example

    Alarm Rule Name

    The name of the alert rule.

    Maximum number of vCPUs for preemptible instances for limited purchase

    Alarm Metric

    The metric used by the alert rule. Valid values:

    • Quotas

    • Used Quotas

    • Percentage of Used Quotas(%)

    • Percentage of Available Quotas(%)

    Percentage of Used Quotas(%)

    Threshold and Alert Level

    The alert level and the threshold corresponding to this level.

    The following default notification methods are set for different alert levels:

    • Critical: Email and Callback

    • Warning: Email and Callback

    • Info: Email and Callback

    You also need to select the number of times that the threshold is reached before an alert is triggered. Valid values: 1 Consecutive Cycle, 3 Consecutive Cycles, 5 Consecutive Cycles, 10 Consecutive Cycles, 15 Consecutive Cycles, 30 Consecutive Cycles, 60 Consecutive Cycles, 70 Consecutive Cycles, 90 Consecutive Cycles, 120 Consecutive Cycles, and 180 Consecutive Cycles.

    You can configure settings for different alert levels. This way, CloudMonitor generates alerts at a specific level based on the threshold corresponding to the level and sends alert notifications by using the specified methods.

    • Alert level: Info. The default notification method for this alert level is Email and Callback.

    • Threshold: ≥ 80%.

    Mute For

    The interval at which alert notifications are sent if the generated alert is not cleared. The value also indicates the silence period. Valid values: 5 minutes, 15 minutes, 30 minutes, 60 minutes, 3 hours, 6 hours, 12 hours, and 24 hours.

    An alert notification is sent when a metric reaches the alert threshold. During the silence period, if the metric repeatedly exceeds the alert threshold, no new alert notification is sent. After the silence period ends, if the metric does not return to the normal state, a new alert notification is sent.

    For example, if you set the Mute For parameter to 24 hours, CloudMonitor sends an alert notification for a generated alert, and the alert remains unresolved, CloudMonitor sends a new alert notification after 24 hours.

    5 minutes

    Effective Time

    The period during which the alert rule takes effect. The alert rule takes effect and generates alerts only at the specified time on the specified days of a week.

    • Cycle: Monday to Sunday

    • Time: 00:00 to 23:59

    Alarm Contact Group

    The contact group to which alert notifications are sent.

    Alert notifications for an application group are sent to the alert contact in the alert contact group. An alert contact group is a group of alert contacts, containing one or more alert contacts.

    For more information about how to create an alert contact or an alert contact group, see Create an alert contact or alert contact group.

    Quota Administrators of ECS Instance Types

    Alarm Callback

    The URL that is accessible over the Internet to receive the alert information pushed by CloudMonitor by using HTTP POST requests. Only the HTTP protocol is supported.

    To test the connectivity of the callback URL, perform the following operations:

    1. Click Test next to the callback URL.

      On the Test Result page, you can check the connectivity of the callback URL based on the returned status code and test result details.

      Note

      You can also set the Language parameter and then click Test again to obtain test result details of the specified language.

    2. Click Close.

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

    Labels

    The tags of the alert rule. A tag consists of a tag key and a tag value. You can specify up to six tags for an alert rule.

    k1,v1

    Push Channel

    The Alibaba Cloud service used to deliver alert information. Valid values:

    • Simple Log Service

      If you turn on Simple Log Service, when an alert is generated, alert information is sent to a Logstore in Simple Log Service. In this case, you must configure the Region, ProjectName, and Logstore parameters.

      For information about how to create a project and a Logstore, see Getting Started.

    • Message Service - topic

      If you turn on Message Service - topic, when an alert is generated, alert information is sent to a topic in Simple Message Queue (formerly MNS). In this case, you must specify a region and a topic.Simple Message Queue (formerly MNS)

      For more information about how to create a topic, see Create a topic.

    • Function Compute

      If you turn on Function Compute, when an alert is generated, alert information is sent to Function Compute to be formatted. In this case, you must specify a region, a service, and a function.

      For information about how to create a service and a function, see Quickly create a function.

    Turn off all switches

    Recovery Notification

    Specifies whether to send notifications when alerts are cleared. The switch is turned on by default.

    Turn on the switch

    Method to handle alarms when no monitoring data is found

    The method that is used to handle alerts when no monitoring data is available. Valid values:

    • Do not do anything (default)

    • Send alarm notifications

    • Treated as normal

    Do not do anything

  5. In the left-side navigation pane, click Quota Alerts. On the Quota Alerts page, view the details about the alert rules.

    On the Quota Alerts page, you can manage alert rules. For example, you can view, modify, and delete alert rules.

  6. Optional. View the result of an alert callback.

    If you configure the Alert Callback parameter, you can view the alert callback records and applications that are automatically submitted to increase the quota after the alert callback succeeds.

    1. In the left-side navigation pane, click Alert History to view the alert callback records.

      If Alert Callback is displayed in the Notification Methods column of the record, the alert callback succeeded.

    2. In the left-side navigation pane, click Application Records to view the application that is automatically submitted to increase the quota.

Procedure (SLB console)

  1. Log on to the SLB console. In the left-side navigation pane, click Quota Center.

  2. On the Quota Center page, click the ALB tab.

  3. In the Quota Type section, click the General Quota tab, find the quota that you want to manage, and then click Create Alert Rule in the Actions column.

  4. On the Create Alarm Rule page, configure the parameters and click Confirm.

    Table 1 Parameters for creating an alert rule for a quota item

    Parameter

    Description

    Example

    Alarm Rule Name

    The name of the alert rule.

    Maximum number of vCPUs for preemptible instances for limited purchase

    Alarm Metric

    The metric used by the alert rule. Valid values:

    • Quotas

    • Used Quotas

    • Percentage of Used Quotas(%)

    • Percentage of Available Quotas(%)

    Percentage of Used Quotas(%)

    Threshold and Alert Level

    The alert level and the threshold corresponding to this level.

    The following default notification methods are set for different alert levels:

    • Critical: Email and Callback

    • Warning: Email and Callback

    • Info: Email and Callback

    You also need to select the number of times that the threshold is reached before an alert is triggered. Valid values: 1 Consecutive Cycle, 3 Consecutive Cycles, 5 Consecutive Cycles, 10 Consecutive Cycles, 15 Consecutive Cycles, 30 Consecutive Cycles, 60 Consecutive Cycles, 70 Consecutive Cycles, 90 Consecutive Cycles, 120 Consecutive Cycles, and 180 Consecutive Cycles.

    You can configure settings for different alert levels. This way, CloudMonitor generates alerts at a specific level based on the threshold corresponding to the level and sends alert notifications by using the specified methods.

    • Alert level: Info. The default notification method for this alert level is Email and Callback.

    • Threshold: ≥ 80%.

    Mute For

    The interval at which alert notifications are sent if the generated alert is not cleared. The value also indicates the silence period. Valid values: 5 minutes, 15 minutes, 30 minutes, 60 minutes, 3 hours, 6 hours, 12 hours, and 24 hours.

    An alert notification is sent when a metric reaches the alert threshold. During the silence period, if the metric repeatedly exceeds the alert threshold, no new alert notification is sent. After the silence period ends, if the metric does not return to the normal state, a new alert notification is sent.

    For example, if you set the Mute For parameter to 24 hours, CloudMonitor sends an alert notification for a generated alert, and the alert remains unresolved, CloudMonitor sends a new alert notification after 24 hours.

    5 minutes

    Effective Time

    The period during which the alert rule takes effect. The alert rule takes effect and generates alerts only at the specified time on the specified days of a week.

    • Cycle: Monday to Sunday

    • Time: 00:00 to 23:59

    Alarm Contact Group

    The contact group to which alert notifications are sent.

    Alert notifications for an application group are sent to the alert contact in the alert contact group. An alert contact group is a group of alert contacts, containing one or more alert contacts.

    For more information about how to create an alert contact or an alert contact group, see Create an alert contact or alert contact group.

    Quota Administrators of ECS Instance Types

    Alarm Callback

    The URL that is accessible over the Internet to receive the alert information pushed by CloudMonitor by using HTTP POST requests. Only the HTTP protocol is supported.

    To test the connectivity of the callback URL, perform the following operations:

    1. Click Test next to the callback URL.

      On the Test Result page, you can check the connectivity of the callback URL based on the returned status code and test result details.

      Note

      You can also set the Language parameter and then click Test again to obtain test result details of the specified language.

    2. Click Close.

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

    Labels

    The tags of the alert rule. A tag consists of a tag key and a tag value. You can specify up to six tags for an alert rule.

    k1,v1

    Push Channel

    The Alibaba Cloud service used to deliver alert information. Valid values:

    • Simple Log Service

      If you turn on Simple Log Service, when an alert is generated, alert information is sent to a Logstore in Simple Log Service. In this case, you must configure the Region, ProjectName, and Logstore parameters.

      For information about how to create a project and a Logstore, see Getting Started.

    • Message Service - topic

      If you turn on Message Service - topic, when an alert is generated, alert information is sent to a topic in Simple Message Queue (formerly MNS). In this case, you must specify a region and a topic.Simple Message Queue (formerly MNS)

      For more information about how to create a topic, see Create a topic.

    • Function Compute

      If you turn on Function Compute, when an alert is generated, alert information is sent to Function Compute to be formatted. In this case, you must specify a region, a service, and a function.

      For information about how to create a service and a function, see Quickly create a function.

    Turn off all switches

    Recovery Notification

    Specifies whether to send notifications when alerts are cleared. The switch is turned on by default.

    Turn on the switch

    Method to handle alarms when no monitoring data is found

    The method that is used to handle alerts when no monitoring data is available. Valid values:

    • Do not do anything (default)

    • Send alarm notifications

    • Treated as normal

    Do not do anything

  5. Find the quota that you want to manage and choose image.png > Alert Settings in the Actions column.

  6. In the Alerts dialog box, you can view the alert rules.

References