ALB的配额计算方式有哪些 - 容器服务 Kubernetes 版 ACK

配额（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分钟后发送告警通知。当您的告警回调采用与钉钉机器人的Webhook方式集成时，必须先设置钉钉机器人的自定义关键字为告警，再复制Webhook地址作为告警回调的URL地址。

在左侧导航栏，单击配额告警，查看创建的配额告警信息。
您可以通过配额告警页面，统一管理已创建的配额告警，如执行查看、修改、删除配额告警操作。
（可选）查看告警回调结果。
如果您设置了告警回调，当告警回调成功时，您可以查看告警回调记录和配额自动提升申请。
1. 在左侧导航栏，单击告警历史，查看告警回调记录。
  当目标告警历史记录的通知渠道中包括告警回调时，说明告警回调成功。
2. 在左侧导航栏，单击申请历史，查看配额自动提升申请。

通过负载均衡控制台创建配额告警

登录负载均衡控制台的配额管理页面。
在配额管理页面，单击应用型负载均衡ALB页签。
选择配额类型为通用配额，找到目标通用配额，在操作列单击创建告警。