Cloud Run连接Cloud SQL触发429配额超限 求无额外成本最优方案

最优方案为Cloud Run配置优化+quotaUser参数注入的组合方案，完全依托已付费的Cloud Run、Cloud SQL资源，无需新增额外支出，无需修改业务代码，可彻底解决当前的Cloud SQL Admin API配额超限问题。 #

具体操作步骤 #

1. 调整Cloud Run运行参数，减少冷启动频次 #

当前配置的max requests per container = 1会导致每一个请求都触发新容器启动，而冷启动过程中Cloud SQL Auth proxy必然会调用Cloud SQL Admin API，是配额消耗过高的核心诱因之一，调整如下：

• 将max requests per container上调至10~100区间，具体数值可根据单容器的CPU、内存负载能力调整，尽可能复用已有容器处理请求，减少冷启动次数
• 将min instances调整为2~5（匹配日常基线流量即可），避免低峰期所有实例销毁，高峰流量到来时批量触发冷启动冲击配额阈值

2. 注入quotaUser参数拆分配额统计维度 #

当前配额限制为Queries per minute per user，默认所有Cloud Run实例的API调用都会统计到同一个用户维度下，注入唯一quotaUser后可将调用拆分到不同用户维度统计，相当于横向扩容配额：

• 在Cloud Run部署配置中新增环境变量CLOUD_SQL_CONNECTION_ARGS，值设置为quotaUser=${CLOUD_RUN_INSTANCE_ID}
• Cloud Run内置的CLOUD_RUN_INSTANCE_ID是每个实例的唯一标识，以此作为quotaUser后，每个实例的API调用会单独统计配额，200个实例的总可调用量可达180次/分钟 * 200，完全覆盖高峰需求

3. 可选兜底操作 #

如果调整后仍有偶发超限情况，可直接在GCP控制台的「IAM与管理-配额」页面，提交Cloud SQL Admin API的Queries per minute per user配额上调申请，常规额度上调申请无需额外付费，一般1个工作日内即可审批通过。 #

该方案相比VPC连接器方案，完全没有额外资源支出，配置调整操作10分钟内即可完成，业务无感知，适配你当前的需求。

内容的提问来源于stack exchange，提问作者mmm