GCP Cloud Run部署后并发数被覆盖为80的原因排查

关键结论 #

run.googleapis.com/concurrency被覆盖为80和cpu-throttling: false没有直接关系，主要问题出在部署配置的加载或优先级上，以下是具体排查方向和修复方案：

1. 部署命令未正确加载cloudrun.yaml #

如果你的Cloud Build部署步骤使用gcloud run deploy命令，但未明确指定--config=cloudrun.yaml参数，Cloud Run会默认采用项目级并发数默认值（通常为80），而非仓库中yaml文件的配置。

检查cloudbuild.yaml中的部署步骤，确保包含类似命令：

gcloud run deploy YOUR_SERVICE_NAME --config=cloudrun.yaml --region YOUR_REGION

2. 部署命令隐式继承默认配置 #

即使指定了配置文件，若部署命令中存在其他可能影响并发数的参数，或引用了项目级默认配置模板，也可能导致yaml中的值被覆盖。可以在部署命令中显式添加--concurrency=4，强制锁定该值：

gcloud run deploy YOUR_SERVICE_NAME --config=cloudrun.yaml --concurrency=4 --region YOUR_REGION

3. yaml配置格式或字段冲突 #

确认cloudrun.yaml中并发数的配置格式正确，需放在metadata.annotations下；同时注意Knative原生字段containerConcurrency和run.googleapis.com/concurrency作用一致，若两者同时设置，Cloud Run会优先识别前者。示例配置：

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: YOUR_SERVICE_NAME
  annotations:
    run.googleapis.com/concurrency: '4'
spec:
  template:
    spec:
      containers:
      - image: YOUR_IMAGE_URL
      containerConcurrency: 4  # 与annotation二选一即可，优先级更高

验证方法 #

• 查看Cloud Build部署日志，搜索"concurrency"相关条目，确认部署过程是否正确读取yaml配置
• 部署后执行gcloud run services describe YOUR_SERVICE_NAME --region YOUR_REGION命令，对比实际生效配置与yaml设置

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