Cloud Run 配置详解：身份、入口、容量与网络
验证：未记录
- 适用版本
- 未记录
- 验证范围
- 尚未登记验证记录。
Cloud Run 实验的配置参考，按服务创建顺序查阅。
服务、任务与版本#
| 对象 | 是什么 | 什么时候选 |
|---|---|---|
| Service | 通过 HTTP 请求或事件调用的服务，提供稳定 URL | 网站、API、Webhook；本系列使用它 |
| Job | 执行到完成的任务，可手动或定时触发 | 批处理、数据迁移；容器完成后退出 |
| Revision | 保存某次部署的镜像与配置，创建后不可修改 | 发布、流量分配、回滚的目标 |
| Instance | 运行某个 Revision 容器的实例，可自动增加或回收 | 承载请求；不要当成固定 VM |
| Traffic tag | 给 Revision 指定的访问标签，如 candidate | 在正式切流前访问候选版本；不是容器镜像 tag |
Service 可按比例把流量分给多个 Revision。镜像 tag（如 hello:v1）可变，digest 标识具体内容；发布记录应保存 Revision 与 digest。资源模型
从哪里创建，以及镜像如何准备#
Console：Cloud Run → Services → Deploy container / Create service，选择 Project、Region、镜像和服务名。镜像可来自 Artifact Registry；源码部署另需构建权限与 API。部署容器
优先与区域数据库部署在同 Region，以减少往返延迟；Serverless NEG 直接引用服务，无须固定容器 VPC IP。
容器端口和启动#
入口容器需监听 0.0.0.0:$PORT；127.0.0.1 无法被平台访问。--port=8080 设置目标端口及 PORT 环境变量，应用须自行使用该值。
平台终止 HTTPS，容器通常提供 HTTP。startup probe 检查启动，liveness probe 判断是否重启；它们与 ALB 的 VM 健康检查分开。
默认可写文件系统消耗内存且不持久；业务数据放 Cloud SQL / Cloud Storage 等存储。容器契约 另规定架构、启动与信号处理要求。
三种身份不要混用#
| 身份 | 做什么 | 本例 |
|---|---|---|
| 部署者 | 创建服务、发布新 Revision；还需能使用runtime Service Account | 你登录 gcloud 的 Google 用户 |
| runtime Service Account | 容器访问 Google API 时使用的身份 | lab-run；按需授予 Secret、Storage、SQL 等权限 |
| 调用者 | 向服务发 HTTP 请求的用户或程序 | lab-caller；授予 roles/run.invoker |
部署者在 runtime SA 上需 actAs（通常由 roles/iam.serviceAccountUser 提供）。跨项目镜像拉取还需给相应 service agent 仓库权限；runtime SA 的业务授权不能替代它。服务身份
IAM 保护的服务通常接收 ID token，audience 标识接收方，本例为 run.app URL。它不同于 Google 管理 API 的 access token；改用 ALB 域名时，仍用受支持的服务 audience 或显式配置自定义 audience。服务间认证
Ingress 和 IAM 是两层控制#
Ingress 管网络来源，IAM 管调用权限。
all不等于匿名公开；放行 ALB 不等于 ALB 会自动替调用者完成认证。
| Ingress | 含义 | 场景 |
|---|---|---|
All（all） |
允许从互联网等支持的入口到达，仍受调用认证约束 | 先验证服务本身；可以保持 IAM 认证 |
Internal（internal） |
只接受符合 Cloud Run 内部来源定义的请求 | 内部服务，不接受外部 ALB 入口 |
Internal + Allow traffic from external Application Load Balancers（internal-and-cloud-load-balancing） |
允许内部来源及外部 ALB 转发 | 用 ALB 作为外部入口，同时阻止互联网直接访问 run.app |
Internal 不是简单的“同 Project 白名单”：
| 来源示例 | 被识别为 internal 的前提 |
|---|---|
| 同 Project 的 Cloud Scheduler / Tasks / Pub/Sub | 使用默认 run.app URL；IAM authentication 仍单独满足 |
| 另一个 Cloud Run service / App Engine | 即使同 Project，也需把调用路由经过被目标识别为 internal 的 VPC；不能只凭项目相同判断 |
| 本机普通公网请求 | 不因操作者拥有项目权限而成为 internal；需要符合规则的私网路径或改用允许的 ALB 入口 |
Shared VPC、VPC Service Controls 的条件见 内部来源规则。
ALB 许可不绑定具体 LB。关联关系是 ALB → Backend service → Serverless NEG → Cloud Run，见 ALB 架构。
| 组合 | 实际效果 |
|---|---|
| All + 要求认证 | 公网可到达，但调用者需要身份和调用权限 |
| Internal + 匿名允许 | 仍必须满足内部来源要求，匿名许可不会突破 ingress |
| Internal and Cloud Load Balancing + 匿名允许 | 可公开访问 ALB；互联网直连 run.app 仍受 ingress 限制 |
| Internal and Cloud Load Balancing + 要求认证 | 经 ALB 到达后仍需有效调用身份；或另外配置受支持的 IAP 方案 |
本例用 allUsers → roles/run.invoker 公开服务；另有关闭 Invoker IAM check 的方式，删除 allUsers 不会重新开启该检查。公开访问还受 Organization Policy 限制。公开服务
实例数、并发、CPU 与内存#
| 配置 | 控制什么 | 选择依据 |
|---|---|---|
| Minimum instances | 保持就绪的最低实例数 | 0 允许空闲缩到零；大于 0 可减少冷启动 |
| Maximum instances | 限制扩容规模 | 结合后端容量设定；不要视为严格数据库连接配额 |
| Concurrency | 单个实例同时处理多少请求 | 依据代码线程安全、内存和处理时长压测 |
| CPU / Memory | 单实例资源 | 单请求开销及并发总开销，内存超限可能导致实例终止 |
| Request timeout | 平台等待请求响应的时长 | 与应用服务器、客户端及 ALB 限制一起核对 |
| CPU allocation / Billing setting | CPU 是否仅在请求期间分配等行为 | 有无请求外后台处理；必须结合当前模式确认 |
平台根据多项负载指标扩缩容，应用须支持多实例和重试；长批处理可选择 Job。并发、扩缩容
服务级和 Revision 级容量设置的范围不同；本实验 --min / --max 使用服务级设置。多个 Revision 同时运行时，数据库连接池还需考虑所有实例与滚动发布阶段。
超时、重试与后台工作#
Cloud Run 返回 504 时，处理该请求的容器不一定停止，代码可能继续写数据库；客户端或上游随后重试，会产生重复操作。写入接口应使用业务幂等键，并协调应用、调用方和平台 timeout。需要脱离请求持续执行的工作，按语义选择 Job 或持久队列，不能把返回 HTTP 响应当作后台任务已被可靠接管。Request timeout
配置与密钥#
普通配置用环境变量，密码与 API key 用 Secret Manager，仅授权 runtime SA 读取所需 Secret。环境变量和挂载方式的版本解析、刷新行为不同，见 Secret 实验及 配置说明。
出站网络：服务主动访问谁#
Ingress 管理别人如何访问 Cloud Run；egress 管理 Cloud Run 如何访问数据库、内部 API 或互联网。
- Direct VPC egress：让服务直接使用指定 VPC、同 Region subnet 的网络路径，无需单独部署连接器。
- Serverless VPC Access connector：另一种通过托管连接器接入 VPC 的方式。选型时核对功能支持与容量，不必与 Direct VPC egress 同时配置。
- private-ranges-only：仅将匹配内部地址范围的流量送入 VPC。
- all-traffic：将所有出站流量送入 VPC；普通公网出口还需相应路由和 NAT 等设计。
私网 Cloud SQL 还需数据库网络路径与认证，Auth Proxy 不自动建立该路径。Direct VPC egress、私网实验
Binary Authorization：检查哪些镜像可部署#
Binary Authorization 是部署时的镜像策略检查服务，例如要求可信流水线对镜像 digest 签发 attestation（签名证明）。
构建镜像 → 测试/扫描 → 生成批准证明 → 部署时核验策略 → 允许或拒绝发布测试、扫描及 attestation 签发由流水线完成；勾选开关不会自动建立这些流程。接入时定义允许条件和签发权限，并验证合规镜像通过、缺少证明的镜像被拒绝。Binary Authorization
发布前检查#
确认目标项目与 Region、镜像与监听端口、运行身份、调用策略、ingress、实例容量和依赖网络。部署后检查 Revision Ready，测试允许的调用成功、应拒绝的入口失败，再切流。日志与常见状态码见 端到端排障。