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 FunctionsCloud 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 GKECloud 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-slimWORKDIR /appCOPY requirements.txt .RUN pip install –no-cache-dir -r requirements.txtCOPY . .ENV PORT8080EXPOSE 8080CMD [“python”, “app.py”]Cloud Run 要求容器监听环境变量 PORT 指定的端口默认 8080应用启动时读取这个环境变量绑定端口import osfrom flask import Flaskapp Flask(__name__)app.route(“/”)def index():return “Cloud Run is running”app.route(“/health”)def health():return {“status”: “ok”}, 200if __name__ “__main__”:port int(os.environ.get(“PORT”, 8080))app.run(host”0.0.0.0″, portport)构建镜像并推送到 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 Registrydocker push asia-east2-docker.pkg.dev/my-project/my-repo/my-app:v1部署到 Cloud Rungcloud run deploy my-service \–imageasia-east2-docker.pkg.dev/my-project/my-repo/my-app:v1 \–regionasia-east2 \–platformmanaged \–allow-unauthenticated \–port8080 \–memory512Mi \–cpu1 \–concurrency80 \–min-instances0 \–max-instances100部署完成后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-revisionsmy-service-00002-xyz20,my-service-00001-abc80 \–regionasia-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 Boostgcloud run deploy my-service \–imageasia-east2-docker.pkg.dev/my-project/my-repo/my-app:v1 \–regionasia-east2 \–min-instances1 \–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 \–imageasia-east2-docker.pkg.dev/my-project/my-repo/my-app:v1 \–regionasia-east2 \–networkproduction-vpc \–subnetapp-subnet \–vpc-egressprivate-ranges-only–vpc-egressprivate-ranges-only 表示只有目标为私有 IP 范围的流量通过 VPC 路由公网请求仍走 Google 默认网络不产生不必要的 VPC 流量费用。服务账号的权限管理同样重要。Cloud Run 实例默认使用 Compute Engine 默认服务账号权限过宽生产环境应为每个 Cloud Run 服务创建专用服务账号只授予该服务实际需要的最小权限集合。计费方式与成本控制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-central1vCPU 使用180,000 vCPU-秒$0.00002400/vCPU-秒内存使用360,000 GiB-秒$0.00000250/GiB-秒请求次数200 万次$0.40/百万次以上为参考价格以 GCP 控制台当期报价为准不同区域价格有差异。账号开通与代理充值部署 Cloud Run 服务需要有效的谷歌云账号。GCP 新账号在首次使用期间有资源观察期部分区域的 Cloud Run 配额可能受限。对于月均 GCP 消耗在 $500 以上的团队通过谷歌云代理商充值可以享受赠金返点充值 $1000 到账 $1150充值 $3000 到账 $3500叠加 Cloud Run 的免费额度和 CUD 折扣年度实际成本明显低于官网直充付款支持 多货币 和对公转账。
