Google PCD: 计算、容器和 Serverless 运行时平台 — 学习指南

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

属于 Google Professional Cloud Developer — 学习指南. 使用经过验证的答案练习： Google 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Google Cloud 提供多种运行时平台，涵盖无服务器、容器和虚拟机。选择合适的平台取决于工作负载的特性，例如请求模式、状态管理、构建和发布纪律、运维模型以及网络限制。本节将介绍 Cloud Run、App Engine、Cloud Functions、Google Kubernetes Engine (GKE) 和 Compute Engine 的设计原则、故障模式和权衡取舍，以及用于镜像、身份、网络、配置和运维的支持服务。

无服务器运行时：Cloud Run、App Engine、Cloud Functions

Cloud Run

模型：完全托管的容器，用于处理 HTTP 请求，或以容器化作业的形式运行至完成。
修订版本与流量：每次部署都会创建一个不可变的修订版本。通过按百分比在不同修订版本之间拆分流量，可以实现金丝雀和蓝绿部署模式，并支持即时回滚。例如：

  gcloud run services update-traffic my-svc --to-revisions rev-green=90,rev-blue=10

并发与扩缩：默认并发数为 80；对于 CPU 密集型或非线程安全的代码，可设置为 1。较高的并发度可以减少冷启动放大效应和成本，但如果单次请求的 CPU/内存不足，可能会增加尾部延迟。Cloud Run 可根据传入请求速率扩容或缩容至零；通过设置最小/最大实例数来控制，以减少冷启动并限制成本。
CPU 分配：选择“CPU 始终分配”可在请求之间执行后台工作，但这会产生额外费用；否则，CPU 仅在处理请求时分配。
作业：Cloud Run Jobs 会并行运行 N 个任务直至完成，并为每个任务和整个作业设置了最大重试次数和超时时间；适用于 ETL、批处理和扇出处理。故障模式包括当许多任务指向同一依赖项时，可能导致后端出现热点；应添加速率限制和带退避策略的重试机制。
网络：可通过公网访问、通过 IAM 进行身份验证，或通过 Serverless VPC Access 和 Private Service Connect 部署在 VPC 之后实现私有访问。

App Engine

环境：
- 标准环境：沙盒化、可快速扩缩、针对不同语言提供固定的运行时；具有低冷启动延迟和自动扩缩功能；但文件系统、请求超时和入站请求大小受限。对于大文件上传，请使用 Cloud Storage 签名 URL。
- 灵活环境：基于 Docker，具备类似虚拟机的能力，支持自定义运行时，扩容速度比标准环境慢，支持后台线程和向本地磁盘写入。
服务与版本：一个服务（微服务）可以托管多个版本；可以像 Cloud Run 一样按百分比在不同版本间路由流量。使用 dispatch.yaml 将特定路径或主机路由到不同服务，以实现简单的集中式路由，无需外部负载均衡器。
扩缩：标准环境中支持手动、基本或自动扩缩；灵活环境中基于虚拟机数量进行扩缩。权衡：激进的自动扩缩能提高响应速度，但可能增加成本和后端争用。
常见陷阱：无配额限制的实例无限扩缩可能会压垮下游系统；应强制执行配额和熔断器。

Cloud Functions

事件驱动的处理程序：由 HTTP、Pub/Sub、Cloud Storage 或 Eventarc 事件触发。使用第二代函数可利用 Cloud Run 的执行模型、VPC 出口控制和并发功能；第一代函数一次只处理一个请求。
重试与幂等性：后台函数在失败时可能会被重试；应设计幂等的处理程序，并使用去重键来避免重复处理。HTTP 触发器不会由平台重试；客户端应实现带指数退避的重试机制。
运行时配置：环境变量、与 Secret Manager 集成，以及针对每个函数的并发/最大实例数配置。设置超时以控制成本失控。注意大型依赖项可能导致较长的冷启动时间；应保持软件包精简。

Google Kubernetes Engine 上的容器

工作负载

Deployments：用于无状态 Pod 的滚动更新。通过设置浪涌/不可用限制来确保安全发布：

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

StatefulSets：为有状态服务提供有序、稳定的网络 ID 和持久卷。
DaemonSets、Jobs、CronJobs：用于节点级代理和批处理工作负载。

Service 与 Ingress

Service 类型：
- ClusterIP 用于仅内部访问。
- NodePort 用于简单的外部访问（操作上受限）。
- LoadBalancer 用于区域性的外部/内部负载均衡。
Ingress：用于 HTTP(S) 路由和 TLS 终止；推荐使用 Gateway API 或带有托管控制器的 Ingress 来实现 L7 策略。故障模式：健康检查因防火墙规则而失败；应允许负载均衡器的 IP 范围访问后端节点。

自动扩缩与节点池

Horizontal Pod Autoscaler (HPA)：根据 CPU、内存或自定义指标扩缩 Pod；与 Pod Disruption Budgets 结合使用以保护可用性。
Vertical Pod Autoscaler (VPA)：合理调整 Pod 的资源请求/限制；避免在同一维度上同时使用 HPA 和 VPA，以防出现反馈循环。
Cluster Autoscaler：根据待处理的 Pod 资源请求来增加/移除节点。
节点池：按工作负载类别划分不同的节点池。使用污点/容忍（taints/tolerations）和标签进行调度。对于成本敏感且能容忍中断的工作负载，可混合使用 Spot/抢占式实例。选择具有足够内存带宽/CPU 的机器类型，以避免因 Pod 资源限制而导致的节流。

健康状况与发布

存活、就绪和启动探针可防止流量发送到未就绪的 Pod，并重启死锁的容器。过于严格的存活探针可能导致级联重启；应调整初始延迟和失败阈值。
回滚：使用 kubectl rollout undo 进行回滚。对于金丝雀发布，可使用多个 Deployment 并通过 Ingress/Gateway 实现 Service 级别的流量拆分。

用于应用负载的 Compute Engine

虚拟机设计

实例模板定义了机器类型、镜像、磁盘、服务账号范围、启动脚本和元数据。保持镜像最小化；使用启动脚本或由 Packer 构建的镜像来实现确定性启动。
磁盘：对延迟敏感的应用使用平衡或 SSD 永久性磁盘。通过将只读永久性磁盘挂载到多个实例，在托管实例组中共享大型只读数据集，以实现低延迟和快速启动。
网络：使用负载均衡器时，为健康检查器创建防火墙规则。例如：

  gcloud compute firewall-rules create allow-lb \
    --network my-net --allow tcp \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 --direction INGRESS

托管实例组 (MIG)

可按 CPU、负载均衡器每秒请求数、自定义指标或时间表进行自动扩缩。设置冷却时间以防止系统抖动。
通过健康检查进行自动修复，可重启不健康的虚拟机；确保健康检查路径测试的是应用就绪情况，而不仅仅是端口可达性，以避免提供 500 错误。
滚动更新和蓝绿部署：创建一个新的实例模板，并对一部分实例启动金丝雀更新。如果错误率上升，则回滚到上一个模板。正常运行时间检查和基于 SLO 的提醒可快速检测到服务降级。

日志记录与监控

安装代理以收集应用日志，无需更改代码；将日志传送到 Cloud Logging 并通过 Cloud Monitoring 发出提醒。使用 Debug Logpoints 进行实时诊断，并将干扰降至最低。

构建、身份、网络、密钥和运维

Artifact Registry 和镜像

使用 Artifact Registry 存储容器镜像和语言工件。启用漏洞扫描和来源生成。保持镜像精简：
- 使用多阶段构建来分离构建时和运行时。
- 最终镜像中避免包含开发工具；固定操作系统和软件包的版本。示例：

  FROM golang:1.22 AS build
  WORKDIR /src
  COPY . .
  RUN CGO_ENABLED=0 go build -o app

  FROM gcr.io/distroless/base-debian12
  COPY --from=build /src/app /app
  ENTRYPOINT ["/app"]

晋升：为镜像打上不可变标签（例如，app:1.3.7, app:prod-20240901），并通过在 Artifact Registry 中重新打标签来晋升；在生产环境中避免使用可变的 latest 标签。通过集成和金丝雀测试结果来控制晋升流程。

运行时身份和最小权限

为每个工作负载分配一个专用的服务账号，并授予所需的最小 IAM 角色。避免使用如 Editor 这样的宽泛角色。在 GKE 中，通过 Workload Identity 将 Kubernetes ServiceAccount 映射到 Google 服务账号。对于无服务器服务，明确设置运行时服务账号并移除默认令牌范围。

VPC 连接器和服务网络

无服务器 VPC 访问连接器将来自 Cloud Run、Cloud Functions 和 App Engine 的出站流量路由到 VPC。选择出站模式：
- 仅私有范围：用于访问 RFC1918 和 VPC 连接的服务，而公网出站流量则直接访问。
- 所有流量：通过连接器和 Cloud NAT 路由，以获得确定的出站 IP 并实施受限的出站策略。
私有依赖：对于 Cloud SQL 优先使用 Private IP，对于 Google API 或合作伙伴服务则使用 Private Service Connect。确保连接器与区域匹配且大小能满足吞吐量需求；监控连接器的 CPU 以避免节流。

配置、密钥和健康检查

使用环境变量存储非敏感配置。将密钥存储在 Secret Manager 中，并在运行时挂载或注入；定期轮换密钥。在 GKE 中，使用 Secrets 和 Secret Manager 的 CSI 驱动程序。在 App Engine 和 Cloud Run 中，授予服务账号对特定密钥的访问权限。
健康检查：
- Cloud Run：实例在崩溃时会重启；使用请求级别的检查和延迟 SLI。
- App Engine：内置健康检查；为 Flexible 环境自定义 liveness/readiness 检查。
- GKE：配置 liveness/readiness/startup 探针。
- 负载均衡器后的 Compute Engine：使用针对特定应用端点的 HTTP(S) 健康检查。

故障排查、回滚和发布模式

在 Cloud Run 和 App Engine 上通过流量拆分实现蓝绿部署和金丝雀发布；在 GKE 中，使用并行的 Deployment 或渐进式交付控制器；在 MIG 中，使用实例的金丝雀子集。始终根据 SLO 错误预算和延迟定义中止标准。
常见故障模式：
- 从零扩容或大规模部署后出现惊群效应；通过设置最小实例数、预热和速率限制来缓解。
- 超出后端配额或连接限制；应用指数退避和熔断器。
- 因镜像过大或依赖项过多导致冷启动；精简镜像并预先初始化客户端。

实际问题场景

Acme 零售公司计划将其图像大小调整 API 从自管理的虚拟机迁移到一个可扩展、成本效益高、响应延迟低、能私密访问区域性 Cloud Storage 存储桶并支持安全金丝雀发布的平台。

方法

将服务打包成一个小型容器镜像，并发布到 Artifact Registry。

理由：一个精简的多阶段 Docker 构建可以最大限度地减少冷启动和网络传输。Artifact Registry 集中了扫描和晋升工作流。

将 API 部署到 Cloud Run，设置最小实例数为 2，并发数为 40，并禁用 CPU 始终分配。

理由：Cloud Run 提供即时的水平扩展和托管的 HTTPS。一个小的最小实例池可以减少日常高峰期的冷启动延迟。40 的并发数在成本和 I/O 密集型图像转换的尾部延迟之间取得了平衡。禁用 CPU 始终分配可以避免为请求之间的空闲计算付费。

创建一个无服务器 VPC 访问连接器，并将出站流量设置为“仅私有范围”；在子网中启用 Private Google Access，并根据需要为 Cloud Storage 配置 VPC-SC 或 Private Service Connect 端点。

理由：该 API 必须在没有公共出站流量的情况下私密地获取和写入图像。“仅私有范围”模式确保只有 VPC 流量通过连接器，从而保持公共调用直接且高效。Private Google Access 或 Private Service Connect 提供了从 VPC 私密访问 Google API 的能力。

为一个专用的运行时服务账号授予对目标 Cloud Storage 存储桶和所需密钥的最小权限访问。

理由：最小权限原则限制了爆炸半径。运行时身份在特定存储桶上获得 storage.objectViewer 和 storage.objectAdmin 角色，并对所需的 Secret Manager 密钥获得 accessor 角色。

将 API 密钥和各环境的配置存储在 Secret Manager 和环境变量中；在运行时注入密钥。

理由：集中化的密钥轮换和可审计的访问。通过环境变量存储非敏感配置支持十二要素应用实践。

实施指数退避和幂等写入，以处理来自 Cloud Storage 的 429/5xx 错误。

理由：在流量突增或区域性事件期间，可能会发生瞬时错误。带有抖动的退避可以保护 API 和 Cloud Storage 免受重试风暴的影响。

配置一个金丝雀修订版本，并将 10% 的流量拆分给它；监控错误率、P95 延迟和饱和度。

理由：Cloud Run 上的流量拆分可实现安全的渐进式部署。基于 SLO 的监控器在错误预算消耗过快时提供自动回滚触发器。

添加一个用于测试下游依赖项的 HTTP 健康端点；在 Cloud Monitoring 的正常运行时间检查和基于日志的指标上设置警报。

理由：端到端的健康状况能及早发现依赖项故障。正常运行时间检查提供了外部视角；基于日志的指标能捕获特定于应用的故障模式。

建立自动扩缩容限制和预算；设置最大实例数以限制开销，并定义过载时的 429 处理方式。

理由：限制扩缩容规模可防止成本失控和后端资源耗尽。优雅的过载行为可维持服务稳定性。

记录回滚方案：通过一个命令将 100% 的流量切回上一个 Cloud Run 修订版本。

理由：不可变的修订版本使回滚既安全又快速，从而最大限度地缩短平均恢复时间。

← 云原生应用架构与服务选择 · 所有领域 · API 设计、集成与事件驱动开发 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

通过考试 →

浏览 Google →