Methods to calculate ALB quotas - Container Service for Kubernetes - Alibaba Cloud ドキュメントセンター

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.

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)

Log on to the Quota Center console.
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.
On the General Quotas page, find the quota that you want to manage and click Create Alert Rule in the Actions column.

In the Create Quota Alert Rule panel, configure the parameters and click OK. The following table describes the parameters.

Parameter	Description
Alarm Rule Name	The name of the alert rule.
Alarm Metric	The metric used by the alert rule. You can select Used Quotas, Percentage of Used Quotas, Available Quotas, or Percentage of Available Quotas.
Threshold	The alert threshold. Configure this parameter based on the Alarm Metric parameter. When the Alarm Metric parameter is set to Used Quotas, alert notifications are sent to the current Alibaba Cloud account if the quota usage of the specified quota item reaches or exceeds the threshold. When the Alarm Metric parameter is set to Percentage of Used Quotas, alert notifications are sent to the current Alibaba Cloud account if the quota usage of the specified quota item in percentage reaches or exceeds the threshold. Valid values: [50%,100%]. When the Alarm Metric parameter is set to Available Quotas, alert notifications are sent to the current Alibaba Cloud account if the remaining quota of the specified quota item is less than or equal to the threshold. When the Alarm Metric parameter is set to Percentage of Available Quotas, alert notifications are sent to the current Alibaba Cloud account if the percentage of the remaining quota of the specified quota item is less than or equal to the threshold. Valid values: (0%,50%].
Alarm Callback	The webhook URL to which Quota Center sends an alert notification by using an HTTP POST request. For more information about the examples of alert callback requests and parameters in an alert callback request, see What is the request content of an alert callback? Note By default, Quota Center sends an alert notification about 15 minutes after the specified alert threshold is reached. If your alert callbacks are integrated with the webhook of a DingTalk chatbot, you must set the custom keyword of the DingTalk chatbot to Alert and then copy the webhook URL as the URL to receive alert callbacks.

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.
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)

Log on to the SLB console. In the left-side navigation pane, click Quota Center.
On the Quota Center page, click the ALB tab.
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.