Google PCD: 持续交付、配置和基础设施自动化 — 学习指南

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

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

概览

Google Cloud 上的持续交付集成了构建自动化、工件管理、部署编排、基础设施即代码以及强有力的治理，从而安全地重复交付变更。稳健的流水线将不可变工件和声明式配置与策略及可审计性相结合。本节将解释在端到端实施 Cloud Build、Cloud Deploy、Artifact Registry、Terraform、Kubernetes、功能标志和治理控制时的设计选择、操作实践和常见故障模式。

构建和部署编排

Cloud Build

• 触发器：将构建连接到源事件（如分支推送、标签、PR）或计划任务。优先使用分支或标签的正则表达式，以确保只有预期的引用 (ref) 会触发构建。触发器可以以特定服务账号运行，以强制执行最小权限原则；如果构建需要广泛的 API 访问权限，请不要依赖默认服务账号。
• 构建步骤：每个步骤都在一个容器中运行。当默认工具链不足时，使用专用构建器（docker、gcloud）或自定义构建器。为编译、单元测试、集成测试、代码检查、安全扫描和工件打包分离步骤，以便于故障归因和有效缓存。
• 替换变量：使用内置变量（PROJECT_ID、SHORT_SHA）和自定义替换变量（以 $_ 为前缀）进行参数化构建。将特定于环境的值排除在构建逻辑之外；将它们作为替换变量传递，或在稍后的部署阶段解析。
• 服务账号：Cloud Build 服务账号 (PROJECT_NUMBER@cloudbuild.gserviceaccount.com) 需要明确的角色（例如，Artifact Registry 写入者、Cloud Deploy 发布管理员）。按项目分配最小化的角色和范围。对于私有资源，请使用具有 VPC 连接的专用池 (Private Pools)。
• 工件：将不可变镜像发布到 Artifact Registry，并可选择通过 artifacts 部分将非容器工件上传到 Cloud Storage。使用语义化版本和提交摘要 (commit digest) 同时标记镜像；在部署中使用镜像摘要以避免标签漂移 (tag drift)。

Cloud Build 配置示例：

• cloudbuild.yaml: steps:

  • name: gcr.io/cloud-builders/docker args: [“build”,"-t","$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}","."]
  • name: gcr.io/cloud-builders/docker args: [“push”,"$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}"]
  • name: gcr.io/cloud-builders/gcloud args: [“deploy”,“releases”,“create”,“app-${SHORT_SHA}”,"–delivery-pipeline=app-pipeline","–images=app=$REGION-docker.pkg.dev/$PROJECT_ID/app/app@sha256:${COMMIT_SHA}"] substitutions: _REGION: us-central1 serviceAccount: projects/$PROJECT_ID/serviceAccounts/cb-deployer@$PROJECT_ID.iam.gserviceaccount.com

• 触发器示例： gcloud builds triggers create cloud-source-repositories –repo=my-repo –branch-pattern=^main$ –build-config=cloudbuild.yaml –service-account=cb-deployer@$PROJECT_ID.iam.gserviceaccount.com

Cloud Deploy

• 交付流水线 (Delivery pipelines) 定义了有序的阶段 (stage) 和目标 (target)。目标引用 GKE 集群、Cloud Run 服务或其他支持的运行时。使用 requireApproval 标记生产阶段，以控制向该阶段的发布。
• 发布 (Rollout) 将一个版本 (release) 映射到一个目标；晋升 (promotion) 则推动一个版本在不同目标之间前进。使用渐进式交付（金丝雀、蓝绿部署）和钩子 (hook) 进行部署前/部署后检查。
• 故障模式：使用可变标签会导致意外升级；务必锁定镜像摘要。部署者账号缺少 IAM 权限会阻塞发布。无法渲染的清单或特定于环境的配置漂移会导致晋升失败；在构建期间验证清单。

Cloud Deploy 定义示例：

• delivery-pipeline.yaml: apiVersion: deploy.cloud.google.com/v1 kind: DeliveryPipeline metadata: name: app-pipeline serialPipeline: stages:

  • targetId: dev
  • targetId: prod strategy: standard: verify: true requireApproval: true

• targets.yaml: apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: dev gke: cluster: projects/PROJECT/locations/REGION/clusters/DEV_CLUSTER

  生产目标定义

  apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: prod gke: cluster: projects/PROJECT/locations/REGION/clusters/PROD_CLUSTER

• 版本创建和晋升： gcloud deploy releases create app-20260903-1 –delivery-pipeline=app-pipeline –region=us-central1 –images=app=us-central1-docker.pkg.dev/PROJECT/app/app@sha256:IMAGE_DIGEST gcloud deploy releases promote –delivery-pipeline=app-pipeline –release=app-20260903-1 –region=us-central1

工件和供应链完整性

Artifact Registry

• 仓库：按团队或环境创建独立的仓库，以限定 IAM 和清理策略的范围。使用靠近构建器和运行时的区域性仓库，以减少出口流量和延迟。包格式包括 Docker 镜像和语言包（Maven、npm、PyPI）。
• 保留策略：定义清理策略以移除未被引用或过时的标签，并保留一个用于回滚的安全窗口。避免过于激进的保留策略，以免删除最后一个已知良好版本。
• 来源和软件物料清单 (SBOM)：启用构建来源，使镜像携带符合 SLSA 标准的证明 (attestation)。在构建期间生成 SBOM 并将其作为证明存储，以改进漏洞分类处理。
• 漏洞扫描：启用容器分析，并在检测到没有可用修复程序或策略豁免的高危 CVE 时，中断构建或阻止晋升。
• 权衡取舍：将所有工件集中在单个项目中可以简化治理，但可能会产生巨大的爆炸半径；按环境或按应用程序设置仓库可以降低风险，但会增加管理开销。

供应链强制执行

• GKE 上的 Binary Authorization 可以要求提供证明（例如，“由项目 X 中的 Cloud Build 构建”、“无严重 CVE”）。与 Cloud Deploy 的门控集成，以阻止不合规的发布。
• 故障模式：依赖可变标签、禁用扫描或未经身份验证的拉取可能导致未经核验的软件进入生产环境。锁定摘要并要求提供证明。

基础设施即代码与 GitOps

Terraform

• 配置与模块：将可复用模块分解为具有清晰输入/输出和语义化版本的单元。将模块发布到共享仓库或注册中心；锁定版本以避免意外变更。
• 状态 (State)：使用 GCS 后端存储远程状态，并配置存储桶级别的 IAM、对象版本控制和 CMEK。保护状态文件不被手动编辑，并确保状态加密。通过在 apply 时从 Secret Manager 读取以及谨慎使用 data source，来避免将密钥存储在状态文件中。 terraform { backend “gcs” { bucket = “tf-state-prod” prefix = “networking” } }
• 计划 (Plan) 与应用 (Apply)：运行 terraform plan 时使用 -out 参数，并通过人工或自动化门禁审查差异；只应用先前已批准的计划。在漂移检测作业中使用 -refresh-only 或 -detailed-exitcode。
• 环境隔离：每个环境使用独立的项目、状态存储桶和服务账号。对于复杂组织，优先选择“每个环境一个目录”并配合变量文件的方式，而不是使用 workspace。切勿在不同环境间共享状态。
• 故障模式：并发 apply 会损坏状态；通过 CI/CD 和锁定机制（GCS 使用对象前置条件）强制执行序列化操作。手动在控制台进行更改会导致漂移；限制直接修改操作，并定期运行 plan 作业进行检测。

Kubernetes 声明式配置

• 清单 (Manifests)：保持 Kubernetes 对象的声明式特性；在生产流程中避免使用 kubectl 命令式操作。锁定镜像的摘要 (digest) 以及资源的 requests/limits。
• Kustomize：使用 base + overlays 的方式来处理环境特定的补丁，从而避免 fork chart。 kustomization.yaml (overlay): resources:
  • ../../base patches:
  • target: kind: Deployment name: api patch: |
    • op: replace path: /spec/replicas value: 3
• Helm：为每个环境使用独立的 values 文件；明确记录优先级顺序（命令行值覆盖 values 文件，values 文件覆盖 chart 默认值）。在 CI 中进行模板渲染（使用 skaffold render 或 helm template），以确保部署时的配置是不可变的。
• GitOps：将期望状态存储在 Git 中。使用 Cloud Deploy 或 Config Sync 将集群状态与 Git 同步。PR (Pull Request) 成为变更控制的界面，并提供审计跟踪和策略检查。避免使用 kubectl exec 进行未在 Git 中记录的修改。

发布安全、配置与治理

功能标志和运行时配置

• 功能标志将部署与发布解耦；交付休眠代码，并按群组、百分比或区域启用。将标志定义存储在低延迟、高可用的系统（如 Firestore、Memorystore）中，并使用短 TTL 进行缓存。记录评估过程以实现可追溯性。
• 渐进式发布：将流量拆分（Cloud Run）或金丝雀子集（GKE）与功能标志相结合，以最小化爆炸半径。使用健康指标和基于 SLO 的自动回滚触发器。
• 安全回滚：优先通过功能标志进行快速禁用。对于二进制文件回滚，提升上一个已知良好的版本或重新应用先前的清单摘要（manifest digest）。

环境变量、优先级、密钥

• 优先级通常遵循：运行时标志 > 环境变量 > 配置文件 > 代码默认值。在所有服务中对此进行文档化和标准化。
• 使用 ConfigMaps 和环境变量注入配置；对敏感值使用 Secret Manager 或 Kubernetes Secrets。定期轮换密钥，避免将密钥烘焙到镜像中。
• 密钥注入示例：
  • Cloud Run 环境变量： gcloud run services update api –update-secrets=DB_PASSWORD=projects/PROJECT/secrets/db_password:latest
  • GKE Secret Manager CSI： apiVersion: v1 kind: Pod metadata: name: app spec: volumes:
    • name: sm csi: driver: secrets-store.csi.k8s.io readOnly: true volumeAttributes: secretProviderClass: gsm-secrets containers:
    • name: app volumeMounts:
      • name: sm mountPath: /secrets

CI/CD 中的质量门禁

• 单元测试在每次提交时运行；快速反馈至关重要。
• 集成测试针对使用种子数据的临时环境或沙箱运行。
• 安全检查：SAST、依赖项扫描、容器漏洞扫描、IaC 策略检查（Conftest、Policy Controller）。在发现严重问题时阻止合并或晋级。
• 部署检查：Cloud Deploy 的部署前和部署后操作可验证就绪状态、数据库迁移安全性和冒烟测试。

分支、代码审查、版本控制、可追溯性

• 优先采用基于主干的开发模式，使用短生命周期的功能分支和强制性的 PR 审查。强制执行必要的检查和线性历史记录以保证可审计性。
• 版本控制：为发布使用语义化版本标签；为不可变性使用镜像摘要（image digests）和提交 SHA。避免在生产部署中使用 latest 这样的可变标签。
• 可追溯性：使用提交、PR、工单 ID 来注解构建和发布。向 Logging 发送部署事件；为资源附加标签以用于成本和所有权管理。

基础架构漂移、策略、审计、变更控制

• 漂移检测：定时执行 terraform plan -detailed-exitcode；当退出码非零时发出警报。对于集群，Config Sync 确保最终收敛到 Git 状态。
• 策略强制执行：使用 Organization Policy 设置护栏（例如，限制外部 IP），使用 Policy Controller 设置 KRM 约束，使用 Binary Authorization 设置镜像策略。
• 审计日志：启用 Admin Activity 和 Data Access 日志；通过接收器（sinks）将日志路由到中心化的项目，并根据合规性要求设置保留策略。Cloud Asset Inventory 提供变更历史和访问分析。
• 变更控制：对生产环境的晋级进行手动审批，并将理由记录为注解。冻结窗口可以编码为 CI/CD 中的策略检查。确保紧急回滚路径有文档记录并经过演练。

实践问题场景

Acme Retail 需要将一个新的 order-service 部署到开发和生产环境的 GKE 上，要求实现安全的金丝雀发布、严格的策略执行和完整的发布可追溯性。团队必须标准化由 Terraform 管理的基础设施、使用 Kustomize 的声明式 Kubernetes 配置，以及使用 Cloud Build 和 Cloud Deploy 的可审计 CI/CD 流程。

方法：

1. 建立工件仓库和身份

• 创建区域性的 Artifact Registry 仓库 order-docker-dev 和 order-docker-prod。在应用项目中，为 Cloud Build 服务账号授予 roles/artifactregistry.writer 角色，并为 GKE 运行时节点授予相应仓库的 roles/artifactregistry.reader 角色。
• 理由：隔离的仓库可以减小爆炸半径并简化生命周期策略。显式的 IAM 避免了权限过大的默认设置。

2. 为基础设施定义 Terraform 并进行环境分离

• 创建 terraform/envs/dev 和 terraform/envs/prod 目录。每个配置都包含一个使用独立状态存储桶（state buckets）的 GCS 后端、一个 GKE 集群模块，以及 Cloud Deploy 服务账号的 IAM 绑定。在每个环境的受控 CI 作业中运行 terraform init、plan -out=plan.bin 和 apply plan.bin。
• 理由：每个环境独立的状态和项目可以防止意外的跨环境影响；计划文件（plan files）支持审查和可审计的变更控制。

3. 编写声明式的 Kubernetes 基础配置和 Kustomize 覆盖层

• 将 Deployment、Service 和 HPA 的 Kubernetes 清单文件放在 k8s/base 目录中，并按摘要（digest）固定镜像。创建 k8s/overlays/dev 和 k8s/overlays/prod 目录，其中包含副本数、资源请求和配置补丁。使用 Secret Manager CSI 类来管理数据库凭据。
• 理由：使用覆盖层的单一事实来源消除了漂移，并使配置保持 DRY（Don’t Repeat Yourself），同时能够安全地实现特定于环境的差异。

4. 实现具有独立测试和打包步骤的 Cloud Build

• cloudbuild.yaml 文件包含以下步骤：代码风格检查和单元测试，针对一次性开发命名空间的集成测试，容器构建并推送到环境对应的仓库，生成 SBOM 和进行漏洞扫描，以及生成来源信息（provenance）。触发器在向 main 分支发起 PR 时运行测试，在合并时进行打包。构建过程使用一个最小权限的 cb-deployer 服务账号运行。
• 理由：尽早失败的成本很低；分离关注点可以提高可观察性并支持有针对性的重试。最小权限原则降低了供应链风险。

5. 配置具有生产环境手动审批和金丝雀策略的 Cloud Deploy 交付流水线

• 定义一个包含 dev 和 prod 目标的 DeliveryPipeline。prod 阶段需要审批，并使用金丝雀策略（例如，10% 然后 100%）。使用部署前钩子（predeploy hooks）进行模式兼容性检查和冒烟测试；部署后钩子（postdeploy）验证 SLO。
• 理由：渐进式交付限制了爆炸半径并引入了自动化的质量门禁，而手动审批则为生产环境强制执行了人工介入环节。

6. 连接 GitOps 和策略强制执行

• 通过强制审查和检查通过来保护 main 分支。使用 Policy Controller 约束来阻止特权 Pod 并禁止使用可变标签。启用 Binary Authorization，要求在准入前必须有 Cloud Build 来源信息和“无高危 CVE”的证明。
• 理由：策略即代码（Policy-as-code）可以防止有风险的配置到达集群，并提供一致的强制执行。

7. 管理配置和功能标志以实现安全发布

• 将非敏感的运行时配置存储在 ConfigMaps 中；密钥通过 Secret Manager CSI 提供。引入一个从 Firestore 读取的功能标志 order_new_flow，在生产环境中初始发布比例为 1%；标志会以短 TTL 缓存并记录日志。
• 理由：功能标志将发布与部署解耦，从而在出现问题时能够立即禁用，而无需回滚二进制文件。

8. 确保可观察性、漂移检测和可追溯性

• 使用提交 SHA、PR 编号和变更工单来注解构建和发布。将 Cloud Deploy 事件和 GKE 审计日志路由到一个中心的 Logging 项目。夜间的 terraform plan 作业在检测到漂移时发出警报；Config Sync 监控 KRM 的分歧，并根据 Git 进行协调。
• 理由：完整的来源信息和审计跟踪可以加快事件响应速度；持续的漂移检测可以维护基础设施的完整性。

9. 操作回滚和变更控制

• 对于突发事件，首先通过功能标志禁用 order_new_flow。如果需要，在 Cloud Deploy 中将上一个成功的版本晋级到 dev 和 prod 环境。所有对 prod 环境的晋级都需要在发布注解中引用工单，并获得待命 SRE 的批准。
• 理由：功能标志提供了即时缓解措施；不可变的版本发布使可预测的回滚成为可能。审批和注解满足了运营治理和合规性要求。

← 身份、认证与应用安全 · 所有领域 · 可观测性、调试和网站可靠性运维 →

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

浏览 Google →