Google PCNE: 网络自动化、治理和成本运营 — 学习指南

By Laurynas Brazys · 23 August 2026 · #google #PCNE #certification #exam-prep #study-guide

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

概览

在 Google Cloud 上，网络自动化、治理和成本运营是密不可分的学科，它们共同决定了您的网络在大规模运行时有多可靠、多安全、多经济。有效的实践融合了结构良好的资源层次结构、最小权限 IAM、基础设施即代码和事件驱动的工作流，所有这些都以清晰的预算、配额和可审计性为基础。其最终状态是可预测的预配、最少的手动更改、可靠的合规性证据以及透明的网络单位经济效益。

治理和访问控制

• 资源层次结构

  • 组织 → 文件夹 → 项目是权限继承和策略护栏的控制平面。将生产环境和非生产环境放在不同的文件夹中，以隔离策略和配额。在 VPC、子网、路由器、转发规则和实例上使用标签，以进行成本分配和资源定位。
  • Shared VPC 将路由和连接性整合在宿主项目中，同时将计算委托给服务项目。仅共享每个服务项目所需的子网，以遵循显式暴露网络的原则，并减少意外的路由暴露。

• IAM 和最小权限

  • 将网络管理与安全管理分开。Compute Network Admin 授予对网络构造的完全控制权和对防火墙规则的只读访问权限，而 Security Admin 则管理防火墙规则和 SSL 证书。这种分离可以避免操作员权限过大，并与变更控制保持一致。
  • 授予有针对性的角色：
    • 要修改防火墙规则，请在 Shared VPC 上使用 Security Admin。
    • 要管理 VLAN 连接和其他核心网络资源，Compute Network Admin 是合适的。
    • 对于针对特定资源的自动化，如果可行，授予资源级别的权限而不是项目范围的角色，或者创建一个仅限于所需权限的自定义角色。
  • 优先使用服务账号模拟和短期令牌，而不是持久性密钥。在可能的情况下，通过组织策略禁止创建服务账号密钥。使用 Workload Identity Federation 为本地或多云自动化完全移除密钥。
  • 对于数据平面任务，遵循最小权限访问原则。例如，一个读取 Cloud Storage 的作业只需要目标存储桶上的 storage object viewer 权限，而不需要项目范围的宽泛 editor 权限。

• 组织策略

  • 默认情况下对虚拟机强制执行“无外部 IP”；使用 Private Google Access 和 Cloud NAT 在没有公共地址的情况下访问 Google API。
  • 将对等互连和外部共享限制在批准的模式内（例如，限制 VPC 对等互连配置以避免蔓延）。
  • 限制服务账号密钥的创建和服务账号的使用，以限制凭据蔓延。
  • 故障模式和权衡：
    • 在文件夹级别上过于宽泛的继承角色可能会悄悄地授予对许多项目的写访问权限。使用有效权限分析来审查角色绑定。
    • 阻止虚拟机拥有外部 IP 却没有规划 Private Google Access 和 NAT，会在调用 Google 服务时导致中断。
    • 在未重构假定使用自动子网的模板的情况下，将 VPC 从自动模式转换为自定义模式会破坏部署；此后应显式引用自定义子网。

自动化、IaC 和事件驱动的操作

• 使用 Terraform 实现基础设施即代码

  • 使用模块化设计：每个基础组件（VPC、子网、防火墙、Cloud Router、Cloud NAT、互连附件）一个模块，然后组合成环境堆栈。对模块进行版本控制，并在消费堆栈中固定版本，以控制发布。
  • 将状态远程存储并加锁（例如，通过后端模式在 Cloud Storage 中使用 Dynamo 风格的锁），以防止并发更改。加密和备份状态；将状态视为敏感信息。
  • 漂移管理：
    • 通过 CI 中的 pull request 和 terraform plan 强制执行变更，以揭示预期与实际的差异。运行计划的漂移检测 (plan -detailed-exitcode)，并在出现漂移时发出警报。
    • 避免在生产环境中进行临时的 gcloud 更改；如果必须进行紧急修复，请记录下来并立即在代码中进行协调。
  • 幂等性和护栏：始终进行计划、审查和应用。使用有针对性的应用来最小化爆炸半径。使用变量验证和策略即代码（例如，Sentinel 或 OPA）来阻止重叠的 CIDR 或开放的防火墙等反模式。

• gcloud、API 和工作流

  • 对于低延迟的操作任务，使用 gcloud 和 REST，但将它们包装在可重复的脚本中。通过重试和指数退避来处理最终一致性和 API 速率限制。
  • 事件驱动的操作：
    • 使用 Cloud Scheduler + Pub/Sub + Cloud Run/Cloud Functions 来自动化常规任务，例如配额检查、NAT 使用率审计或防火墙日志采样。
    • 将 Admin Activity 和 Data Access 日志流式传输到 Pub/Sub，以触发护栏工作流（例如，自动恢复未经授权的防火墙规则更改）。
  • 示例片段
    • 授予角色：
      • gcloud projects add-iam-policy-binding PROJECT –member=user:alice@example.com –role=roles/compute.networkAdmin
    • 创建一条路由以供 Google API 绕过指向 NGFW 的默认路由：
      • gcloud compute routes create google-apis-egress –network=NET –destination-range=199.36.153.8/30 –next-hop-gateway=default-internet-gateway –priority=800

• 操作陷阱

  • 当多个流水线管理共享资源（例如，公共 VPC 中的防火墙）时，竞态条件会导致状态抖动。使用所有权约定和文件夹范围的流水线。
  • 高并行度下的 API 不稳定性会触发配额错误；按区域和资源类型对操作进行节流和批处理。

成本、配额和容量管理

• 配额和 API 限制

  • 跟踪每个项目和每个区域的配额（地址、转发规则、防火墙规则、互连连接、路由器）。自动化配额监控，并在新环境上线前申请增加配额。将预检配额检查融入 CI 流程以实现快速失败。
  • 通过以下方式进行大规模预配：
    • 区域分片（按区域创建资源以避免区域配额争用）。
    • 预分配（在高峰事件前预留地址并设置路由器）。
    • 分阶段部署（创建、验证，然后挂载后端）。

• 出站流量和拓扑经济性

  • VPC 内部的跨区域流量会产生区域间的出站流量成本。当延迟和成本很重要时，将需要通信的工作负载放置在同一区域，或在区域内复制数据。
  • 对于靠近 us-east1 和 europe-west1 的用户，一个带有区域子网的单一 VPC 可实现私有 RFC1918 通信，最大限度地减少 NAT 和对等连接的开销，同时简化策略和路由。
  • 使用 VPC Network Peering 在项目或部门之间实现低开销连接，无需 NAT 且无传递路由；保持 CIDR 不重叠。使用独立的 VPC 来隔离那些禁止相互通信的部门。
  • Cloud CDN 可减少 HTTP(S) 流量的出站流量并改善延迟；全局 HTTP(S) 负载均衡器是 CDN 的控制平面。网络负载均衡器不会改善 Web 应用的全局延迟，因为它缺少边缘分发和缓存功能。
  • 明智地选择互连方式：在宿主项目中使用带有 VLAN 连接的 Dedicated Interconnect 可以集中管理，并为大型、共享的本地连接降低每个项目的成本。Cloud VPN 与 Cloud Router 相结合，适用于组织之间快速、加密的连接，并可在以后演进为互连。

• 成本分配、预算和预测

  • 为所有网络资源打上部门、环境和成本中心的标签。将账单数据导出到 BigQuery 并计算单位成本（例如，每个服务的出站流量 $/GB）。
  • 在项目、文件夹或标签粒度上创建预算。将警报发送到 Pub/Sub，并连接到 ChatOps 或 Cloud Run 响应程序。在超出预算时自动执行操作（例如，减少日志采样或缩减非关键测试环境的规模）。
  • 优化出站流量：
    • 优先使用 Private Google Access 和 Cloud NAT 而不是外部 IP，以控制出站路径并集中计费。
    • 对于强制隧道拓扑，为 Google API 添加指向默认互联网网关的自定义路由，或为本地环境配置 Private Google Access，以避免流量通过第三方防火墙出现“发夹弯”效应。
    • 通过分析 VPC Flow Logs 和负载均衡器日志来预测容量；并与季节性因素相关联。在高峰期到来之前，合理调整 NAT 网关和互连的容量。

可审计性与卓越运营

• 日志记录与证据

  • Cloud Audit Logs：
    • Admin Activity 日志捕获对 VPC、路由、防火墙、路由器和负载均衡器的控制平面变更；此日志始终开启。应将其集中保留，并根据需要路由到一个使用 CMEK 的安全项目中。
    • 针对网络 API 的 Data Access 日志可能会产生大量数据；应有选择地启用，并应用采样或配置接收器（sink）。
  • VPC Flow Logs 和 Firewall Rules Logging 为事件响应和合规性提供数据平面证据。应按照所需的保留期限进行存储，并使用 BigQuery 建立索引以供调查。
  • 变更记录：要求每一次网络变更都源于 IaC，并附有不可变的计划产物和工单参考。对于特殊的手动变更，应在中央注册表中记录 gcloud 命令、操作员、时间戳和理由。

• 安全凭证与自动化风险控制

  • 消除长期有效的服务账号密钥。使用 IAM Conditions 按资源、时间或 IP 来限定自动化的范围。对于高风险权限（例如 compute.firewalls.update、compute.routers.updateBgpPeer），应使用审批工作流进行保护。
  • 对 CI/CD 应用最小权限原则，使用按环境划分的服务账号，并频繁轮换令牌。在存在数据泄露风险的情况下，使用 VPC Service Controls 进行服务边界保护。

• 运行手册、生命周期与持续改进

  • 为日常操作维护运行手册：将项目接入 Shared VPC、创建 VPC 对等连接、建立使用 IKEv2 的 Cloud VPN、将 Cloud Armor 规则从预览模式切换到强制执行模式。
  • 定义生命周期策略：
    • 使用相同的 Terraform 模块和特定于区域的变量，实现沙盒 → 预发 → 生产环境的晋升。
    • 制定退役操作手册，以安全地移除对等连接、NAT 和路由。
  • 持续改进：
    • 事后复盘应反馈到模块中（例如，添加默认拒绝出口流量并使用显式允许列表，或默认启用 NAT 日志记录）。
    • 定期审查组织策略、标签和预算，检查其是否偏离预期状态。

实际问题场景

Contoso Retail 在北美和欧洲开展业务。用户和服务主要在 us-east1 和 europe-west1 中运行。安全部门要求设置一条指向第三方 NGFW 的默认路由，虚拟机上不能有外部 IP，并集中管理本地（on-prem）连接。公司还需要按部门进行清晰的成本分摊和自动化护栏。

1. 建立治理与拓扑

• 创建一个 Shared VPC 宿主项目，其中包含一个 VPC 和分别位于 us-east1 和 europe-west1 的两个区域子网。理由：一个包含区域子网的 VPC 允许区域间通过简单的路由和策略直接进行 RFC1918 通信，从而最大限度地减少每个项目的开销。
• 仅将必要的子网共享给三个服务项目（市场、供应链、财务）。理由：子网级别的共享在保持集中控制的同时，限制了路由和防火墙的暴露面。
• 为一个必须隔离的遗留财务系统创建一个独立的 VPC；仅在需要时与市场和供应链项目建立对等连接。理由：VPC 对等连接为这两个部门提供了低延迟的私有连接，同时保持了与财务系统的隔离。

2. 在没有公共 IP 的情况下配置对 Google 服务的安全访问

• 在所有共享子网上启用 Private Google Access。理由：没有外部 IP 的实例可以私下访问 Google API。
• 由于默认路由指向一个 NGFW，因此为 199.36.153.8/30 添加一条指向默认互联网网关的自定义静态路由。理由：确保对 Google API 的调用不会通过防火墙形成发夹弯（hairpin），从而降低延迟并避免单一瓶颈点。

3. 集中化本地（On-prem）连接

• 在 Shared VPC 宿主项目中部署 Dedicated Interconnect 和 VLAN 连接，并将其附加到每个区域的一个 Cloud Router 上。理由：集中化的互连可以降低成本和重复操作；Cloud Router 为未来的增长提供动态路由。
• 将 Compute Network Admin 角色授予网络运营团队，将 Security Admin 角色授予安全团队。理由：强制执行最小权限和职责分离；网络管理员未经安全团队批准不能更改防火墙。

4. 自动化预配与护栏

• 为 VPC、子网、路由器、NAT、对等连接和防火墙策略实施 Terraform 模块。使用锁定机制远程存储状态；在 CI 中通过 terraform plan 强制执行拉取请求（pull-request）审查。理由：可重复、版本化且能控制漂移的变更可以最大限度地减少服务中断。
• 添加一个 OPA 策略，以阻止重叠的 CIDR 和向内部子网开放 0.0.0.0/0 的入口流量。理由：在审查阶段防止常见的错误配置。
• 使用 Cloud Scheduler 每天向 Pub/Sub 发布配额检查；一个 Cloud Run 服务调用 Service Usage API 来验证地址、转发规则和互连连接的余量。理由：避免因配额耗尽导致的部署失败。

5. 优化成本并精确分摊

• 通过 Terraform 为所有网络资源应用 env、dept 和 service 标签。将账单导出到 BigQuery，并按部门设置预算，将告警发送到 Pub/Sub。理由：透明的成本分摊和对费用激增的预警使团队能够主动采取行动。
• 使用全局 HTTP(S) 负载均衡器作为公共 Web 资产的前端，并启用 Cloud CDN。理由：通过在边缘提供缓存内容，改善全球用户的延迟并减少出口流量费用。

6. 加强可审计性与事件响应

• 将 Admin Activity 和 Firewall Rules Logging 路由到一个使用 CMEK 的中央日志记录项目。理由：防篡改的变更记录和数据平面证据满足合规性要求。
• 对于有滥用行为嫌疑的客户端，在 HTTP(S) 负载均衡器上以预览模式部署一条 Cloud Armor 规则，并在强制执行前审查日志。理由：在验证缓解措施的同时，最大限度地减少对用户的影响。

7. 文档化与迭代

• 发布运行手册，用于将项目接入 Shared VPC、在市场和供应链项目之间创建 VPC 对等连接，以及为缺少 BGP 的合作伙伴构建基于策略的 Cloud VPN。理由：标准化的执行可以减少平均修复时间（MTTR）和操作差异。
• 在每个变更窗口之后，捕获指标（部署时间、错误数、出口流量费用（美元/GB）、缓存命中率），并将改进反馈到模块和策略中。理由：持续改进将可靠性和成本控制融入日常运营。

← 网络可观测性、可靠性和故障排除 · 所有领域

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

浏览 Google →