Google Cloud Run 是 GCP 提供的全托管无服务器容器平台，基于开源的 Knative 框架构建。它解决的问题是：把容器镜像直接部署上去就能运行，不需要配置虚拟机，不需要管理 Kubernetes 集群，没有请求时缩容到零不产生计算费用，有请求时自动扩容处理流量。
Cloud Run 不限制编程语言和框架，任何能打包成 Docker 镜像的应用都可以在 Cloud Run 上运行。Python、Node.js、Go、Java、Ruby、.NET 均有官方支持，自定义运行时通过容器镜像实现。
Services 与 Jobs：两种运行模式
Cloud Run 提供两种运行模式，针对不同类型的工作负载。
Cloud Run Services 是面向 HTTP 和 gRPC 请求的长期服务模式。部署完成后，Cloud Run 提供一个 HTTPS 端点，客户端向这个端点发送请求，Cloud Run 将请求路由到正在运行的实例处理，支持自定义域名绑定。Services 模式是大多数 Web API、微服务和 Webhook 处理的标准部署方式。
Cloud Run Jobs 是面向批处理任务的运行模式，不处理 HTTP 请求，而是执行到完成后退出。适合数据处理、报表生成、数据库迁移、定时清理任务等工作负载。Jobs 可以配置并行任务数，多个任务副本同时运行加快处理速度，每个任务可以设置最大重试次数，任务失败后自动重试。
两种模式使用相同的容器镜像格式和部署工具，选择依据是工作负载的触发方式：需要响应外部请求选 Services，需要执行后退出选 Jobs。
Cloud Run、Cloud Functions 与 GKE 的选型判断
GCP 提供了多种运行应用的方式，Cloud Run 适合的位置在 Cloud Functions 和 GKE 之间，搞清楚三者的适用场景，可以避免选错平台后期迁移的成本。
Cloud Run vs Cloud Functions
Cloud Functions（现在官方名称是 Cloud Run functions）和 Cloud Run 的底层基础设施已经统一为同一套 Cloud Run 平台，但面向开发者的抽象层次不同。
Cloud Functions 要求部署的是单个函数，带有特定的函数签名，适合事件驱动的简单处理逻辑：Pub/Sub 消息处理、Cloud Storage 文件触发、HTTP Webhook、托管服务之间的胶水代码。Cloud Functions 的运维负担最低，不需要维护 Dockerfile。
Cloud Run 部署的是完整容器，支持多路由（同一服务处理 /api/users、/api/orders 等不同路径）、自定义 OS 依赖、完整的 Web 框架，以及更精细的运行时配置。
两者最关键的成本差别在于并发处理能力。Cloud Functions 默认每个实例同时只处理 1 个请求，80 个并发用户需要 80 个 Cloud Functions 实例同时运行。Cloud Run 默认每个实例可以处理 80 个并发请求，同样 80 个并发用户只需要 1 个 Cloud Run 实例。实例数少，冷启动次数少，内存分配少，成本在中高流量场景下明显低于 Cloud Functions。
判断标准： 单个函数响应单个事件，选 Cloud Functions；需要完整 Web 应用、多路由 API 或自定义容器依赖，选 Cloud Run。
Cloud Run vs GKE
Cloud Run 和 GKE 的对比，本质是托管程度和控制程度之间的权衡。
Cloud Run 完全托管，节点管理、集群升级、容量规划都由 Google 负责，开发者只需要关注应用本身。这带来的限制是：只能运行 HTTP/gRPC 无状态服务（有状态工作负载不适合）、单个请求超时上限 60 分钟、不支持 Kubernetes 的复杂网络拓扑和 StatefulSet。
GKE 提供完整的 Kubernetes 控制面，适合需要复杂网络配置、服务网格、持久化存储、有状态工作负载、或多服务共享集群资源以提高节点利用率的团队。GKE 的运维工作量远高于 Cloud Run，对 Kubernetes 的理解要求也更高。
判断标准： HTTP 无状态服务、团队没有专职 K8s 运维能力，选 Cloud Run；需要有状态服务、复杂网络拓扑、或多服务共享节点降低成本，选 GKE。
部署容器到 Cloud Run
准备容器镜像
Cloud Run 从 Artifact Registry 或 Container Registry 拉取容器镜像。以一个 Python Flask 应用为例，Dockerfile 如下：
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install –no-cache-dir -r requirements.txt
COPY . .
ENV PORT=8080
EXPOSE 8080
CMD [“python”, “app.py”]
Cloud Run 要求容器监听环境变量 PORT 指定的端口（默认 8080），应用启动时读取这个环境变量绑定端口：
import os
from flask import Flask
app = Flask(__name__)
@app.route(“/”)
def index():
return “Cloud Run is running”
@app.route(“/health”)
def health():
return {“status”: “ok”}, 200
if __name__ == “__main__”:
port = int(os.environ.get(“PORT”, 8080))
app.run(host=”0.0.0.0″, port=port)
构建镜像并推送到 Artifact Registry
# 配置 Docker 使用 Google Cloud 凭证
gcloud auth configure-docker asia-east2-docker.pkg.dev
# 构建镜像
docker build -t asia-east2-docker.pkg.dev/my-project/my-repo/my-app:v1 .
# 推送到 Artifact Registry
docker push asia-east2-docker.pkg.dev/my-project/my-repo/my-app:v1
部署到 Cloud Run
gcloud run deploy my-service \
–image=asia-east2-docker.pkg.dev/my-project/my-repo/my-app:v1 \
–region=asia-east2 \
–platform=managed \
–allow-unauthenticated \
–port=8080 \
–memory=512Mi \
–cpu=1 \
–concurrency=80 \
–min-instances=0 \
–max-instances=100
部署完成后，Cloud Run 自动生成一个 HTTPS 端点，格式为 https://my-service-xxxxxxxx-uc.a.run.app。–allow-unauthenticated 表示允许公开访问，不需要 IAM 验证，适合面向公众的 Web 服务；去掉这个参数后，所有请求必须携带有效的 Google 身份令牌。
流量管理与灰度发布
Cloud Run 每次部署都会创建一个新的修订版本（Revision），默认将 100% 流量切换到最新修订版本。通过流量分配，可以实现灰度发布：
# 将 20% 流量切到新版本，80% 保留在旧版本
gcloud run services update-traffic my-service \
–to-revisions=my-service-00002-xyz=20,my-service-00001-abc=80 \
–region=asia-east2
灰度期间观察新版本的错误率和延迟，确认正常后逐步将流量比例切换到 100%。如果新版本出现问题，将流量比例切回旧版本即可完成回滚，不需要重新部署。这个机制让生产环境的版本发布风险可控。
并发配置与自动扩缩容
并发数的设置逻辑
并发数（Concurrency）定义了单个实例同时处理的最大请求数。默认值是 80，范围 1–1000。设置并发数时需要考虑应用的工作特性：
I/O 密集型应用（大量时间等待数据库响应、外部 API 调用）适合高并发设置，因为实例在等待 I/O 期间 CPU 空闲，可以同时处理其他请求。并发设置为 80 时，一个实例实际运行的 CPU 利用率通常不高，资源利用效率高。
CPU 密集型应用（图像处理、加密计算、数据压缩）不适合高并发，因为每个请求都在竞争 CPU。并发设置为 5–10 比较合理，避免多个高 CPU 消耗的请求同时运行导致响应时间显著延长。
自动扩缩容的触发机制
Cloud Run 监控两个指标来决定是否扩容：并发数达到目标值的 60%，或 CPU 利用率达到 60%。当前实例承载的请求量或 CPU 消耗超过这两个阈值之一，Cloud Run 自动创建新实例，新实例就绪后开始分流。
最后一个请求处理完成后，实例不会立即销毁，而是保持最长 15 分钟的空闲状态。这段时间内如果有新请求到来，直接由这个已经热启动的实例处理，不产生冷启动延迟。
–max-instances 设置实例数量上限，防止流量突增时自动扩容超出预期成本。默认上限 100，可根据业务需要调高或调低。设置过低可能导致流量高峰时请求排队等待，设置过高则失去了成本控制的保护。
冷启动与最小实例数配置
冷启动发生在 Cloud Run 需要创建新实例时：从镜像拉取（Artifact Registry 同区域缓存后拉取很快）、运行时初始化、应用代码加载。整个过程通常在 500ms 到 3 秒之间，取决于镜像体积和应用初始化逻辑的复杂程度。
Python 和 Node.js 的冷启动通常在 1 秒以内；带有大量依赖的 Java 应用冷启动可能达到 3–6 秒；使用极简镜像（基于 alpine 或 distroless）的 Go 应用冷启动可以在 200ms 以内。
减少冷启动影响的两种方式：
最小实例数（Min Instances）： 将 –min-instances 设为 1 或更高，Cloud Run 始终保持至少指定数量的实例处于热启动状态，新请求到来时直接处理，不产生冷启动等待。代价是即使没有请求，这些实例也在持续计费（根据计费模式，空闲时 CPU 可能仍被分配）。
一个常驻实例（1 vCPU、512MB 内存）的成本约 $10–12/月，对于面向用户的生产 API，这是避免首次请求延迟的合理成本。
Startup CPU Boost： 启用后，实例初始化期间 CPU 配额临时翻倍，加快应用启动速度。不增加额外费用，Startup CPU Boost 的 CPU 使用量按实际 CPU-秒计费，但启动时间缩短意味着初始化期间的总计费时间减少。
# 部署时启用最小实例数和 Startup CPU Boost
gcloud run deploy my-service \
–image=asia-east2-docker.pkg.dev/my-project/my-repo/my-app:v1 \
–region=asia-east2 \
–min-instances=1 \
–cpu-boost
访问 VPC 内部资源
默认情况下，Cloud Run 实例运行在 Google 管理的网络中，无法直接访问 VPC 内部的私有资源（Cloud SQL、Redis、内网服务）。需要访问 VPC 内部资源时，通过 VPC 连接器（Serverless VPC Access Connector）或直接 VPC 出口（Direct VPC Egress）将 Cloud Run 的出站流量路由到指定 VPC：
# 部署时配置直接 VPC 出口（推荐，不需要额外创建连接器）
gcloud run deploy my-service \
–image=asia-east2-docker.pkg.dev/my-project/my-repo/my-app:v1 \
–region=asia-east2 \
–network=production-vpc \
–subnet=app-subnet \
–vpc-egress=private-ranges-only
–vpc-egress=private-ranges-only 表示只有目标为私有 IP 范围的流量通过 VPC 路由，公网请求仍走 Google 默认网络，不产生不必要的 VPC 流量费用。关于 VPC 子网配置和 Private Google Access 的详细说明，可以参考谷歌云 VPC 网络配置教程。
服务账号的权限管理同样重要。Cloud Run 实例默认使用 Compute Engine 默认服务账号（权限过宽），生产环境应为每个 Cloud Run 服务创建专用服务账号，只授予该服务实际需要的最小权限集合。关于服务账号创建和 IAM 权限配置，可以参考谷歌云 IAM 权限管理教程。
计费方式与成本控制
Cloud Run 提供两种计费模式，适合不同的流量特性。
Request-based billing（请求计费）：CPU 仅在处理请求期间分配计费，实例空闲时（包括等待下一个请求的 15 分钟内）不计算 CPU 费用。适合流量间歇性的场景——每天只在特定时段有请求、或请求频率极低的应用，空闲时间长，按请求计费下空闲不产生成本。
Instance-based billing（实例计费）：CPU 在实例运行期间始终分配，无论是否在处理请求。适合持续有请求、需要在请求间执行后台任务（如缓存预热、连接维护）、或设置了最小实例数需要 CPU 持续可用的场景。
2026 年 Cloud Run 在 us-central1 的免费额度：每月 180,000 vCPU-秒、360,000 GiB-秒和 200 万次请求。这个免费额度对小型应用和开发测试环境通常足够，不需要付费。
| 计费项 | 免费额度/月 | 超出价格（us-central1） |
| vCPU 使用 | 180,000 vCPU-秒 | $0.00002400/vCPU-秒 |
| 内存使用 | 360,000 GiB-秒 | $0.00000250/GiB-秒 |
| 请求次数 | 200 万次 | $0.40/百万次 |
以上为参考价格，以 GCP 控制台当期报价为准，不同区域价格有差异。
账号开通与代理充值
部署 Cloud Run 服务需要有效的谷歌云账号。GCP 新账号在首次使用期间有资源观察期，部分区域的 Cloud Run 配额可能受限。通过谷歌云账号出售渠道获取的稳定账号，配额更宽松，可以直接用于生产环境部署，免实名免绑卡，1 分钟交付。
对于月均 GCP 消耗在 $500 以上的团队，通过 谷歌云代理商 充值可以享受赠金返点（充值 $1000 到账 $1150，充值 $3000 到账 $3500），叠加 Cloud Run 的免费额度和 CUD 折扣，年度实际成本明显低于官网直充，付款支持 USDT 和对公转账。
