Google ACE: VPC 网络、连接性和流量管理 — 学习指南

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

概览

Google Cloud 上的 Virtual Private Cloud (VPC) 网络提供了软件定义的全局网络原语，可对寻址、路由、安全和流量管理进行精细控制。本节重点介绍实践性的设计和运维主题，您将使用这些主题来构建可连接 Google Cloud 服务、本地环境和公共互联网的弹性、安全且可观测的网络。

核心 VPC 架构和 IP 规划

• VPC 网络和子网

  • VPC 是一个全局资源；其子网是区域性的，可以跨可用区。区域内任何可用区的实例都可以使用同一个子网。
  • 生产环境请使用自定义模式的 VPC。自动模式会使用一组预定义的 CIDR 范围在每个区域预创建一个子网，这可能在扩展时导致 IP 地址重叠、地址空间浪费以及重构带来的麻烦。
  • 子网上的次要 IP 范围可用于 GKE Pod/Service IP 和虚拟机的别名 IP。请提前规划主要和次要 CIDR，以避免重新编号。

• IP 地址规划

  • 为您当前和未来可能连接的所有 VPC 及本地网络选择不重叠的 RFC1918 地址空间。为未来的区域和服务预留增长所需的地址块。
  • 为子网规划适当的大小（例如 /24 到 /20）以适应增长，并避免使用过大的范围，因为这会使 ACL 和诊断复杂化。
  • 记录 IP 使用情况：用于工作负载的主要范围，用于 GKE 的次要范围，以及为 NAT 池或服务端点预留的地址块。

• 示例

undefined

undefined

路由、防火墙和策略层次结构

• 路由和动态路由模式

  • 每个 VPC 都有一个路由表，由系统生成的子网路由、默认路由以及自定义的静态或动态路由组成。
  • 动态路由模式：
    • 区域级：通过 Cloud Router 学到的动态 (BGP) 路由只能由同一区域内的资源使用。
    • 全局级：动态路由可由 VPC 中所有区域的资源使用。对于需要从多个区域访问本地环境的混合网络，首选全局模式。
  • 下一跳：默认互联网网关 (0.0.0.0/0)、VPN 隧道、Cloud Router (BGP)、实例（路由设备）或用于虚拟设备的内部负载均衡器下一跳。
  • 路由优先级：数值越小，优先级越高。错误的优先级配置可能导致流量黑洞或泄漏到非预期的下一跳。请使用明确的约定（例如，1000 用于默认出站，900 用于更具体的路由）。

• 防火墙层次结构

  • VPC 防火墙规则是状态化的，在数据包转发前进行评估。它们存在于 VPC 级别，并应用于所有子网。
  • 分层防火墙策略（附加到组织、文件夹或项目）在 VPC 规则之前强制执行允许/拒绝。使用它们来实施中央安全护栏（例如，拒绝暴露于互联网的管理端口）。
  • 隐含规则：存在一条优先级最低的隐含出站允许规则和一条隐含入站拒绝规则；它们无法被移除。所有连接都需要明确的入站允许规则。

• 防火墙规则、标记、服务账号、安全标记

  • 目标：使用网络标记或服务账号将规则应用于特定虚拟机；使用服务账号作为目标可提供更严格的基于身份的控制。
  • 安全标记提供由 IAM 保护的集中管理标签，用于策略定位；它们可以防止工作负载自行附加标签，并支持零信任分段。
  • 日志记录：有选择地为高价值规则启用防火墙日志记录，以平衡可见性与成本；记录数据包样本，而非完整载荷。
  • 常见故障模式：缺少健康检查源范围、非对称路由导致应答包被丢弃、过于宽泛的源范围造成意外暴露。

• 示例

undefined

负载均衡、IP、DNS 和流量管理

• Cloud Load Balancing 类型和行为

  • 基于全球代理：External HTTP(S)、External TCP Proxy、External SSL Proxy。在 Google 的边缘终止客户端连接，支持 anycast 全球 VIP，并插入标头（例如 X-Forwarded-For）。原始客户端 IP 可通过标头或 PROXY 协议（适用于 TCP）获取，而不是作为 L3 源地址保留。
  • 区域级直通：External Network Load Balancer 和 Internal TCP/UDP Load Balancer 在 L4 路由流量并保留客户端 IP。当您需要在后端获得源 IP 可见性且不使用 PROXY 协议时使用。
  • Internal HTTP(S) Load Balancer：适用于内部服务的区域级 L7 代理，提供高级路由和 mTLS 选项。

• 后端服务、健康检查和流量策略

  • 后端服务定义了后端（实例组、NEG/VM/端点、GKE 服务）、均衡模式（UTILIZATION 或 RATE）、容量限制、会话亲和性和连接排空。
  • 必须在防火墙中允许来自 Google 健康检查程序的流量。不健康的后端会被自动移除；配置错误的健康检查可能导致服务完全中断。
  • 流量策略包括位置（区域/可用区）、溢出和故障切换后端，以及某些 LB 类型上用于逐步部署的加权流量拆分。

• 外部和内部 IP、转发规则

  • 外部和内部地址可以是临时的或预留的静态地址。全球静态外部地址由全球 LB 使用；其他大多数是区域性的。
  • 转发规则将 IP:端口 映射到一个目标（例如 targetHttpProxy 或后端服务）。选择全球或区域规则以匹配 LB 类型；不匹配将导致创建失败。

• Cloud DNS

  • DNS 区域 (Zones)：公共区域在公共互联网上解析；私有区域只能从授权的 VPC 解析。使用托管记录（A/AAAA、CNAME、TXT、MX、SRV 等）。
  • 分离式水平 DNS (Split-horizon)：为同一域名创建公共和私有区域，以便内部解析器收到私有应答（例如 ILB IP），而公共用户获得面向互联网的 IP。
  • 私有 DNS 转发：使用 Cloud DNS 策略进行入站和出站转发，以与本地解析器集成；使用 VPC 之间的 DNS 对等互连来共享私有区域，而无需完整的对等互连连接。

• 示例

  • gcloud compute forwarding-rules create web-ilb –region=us-central1 –load-balancing-scheme=INTERNAL_MANAGED –ports=80 –backend-service=web-be

混合和私有连接

• Cloud Router、Cloud NAT 和 Private Google Access

  • Cloud Router 通过 BGP 与本地环境交换路由，通告 VPC 子网，并导入本地前缀。当多个区域需要与本地环境互通时，使用全局动态路由。
  • Cloud NAT 为没有外部 IP 的私有虚拟机和 GKE 节点提供互联网出口。合理规划 NAT IP 池的大小以避免端口耗尽；监控日志中的丢弃连接并相应地扩展地址数量。
  • Private Google Access (PGA) 允许私有虚拟机通过默认路由路径访问 Google API，而无需外部 IP。用于 Google API 的 Private Service Connect (PSC) 在您的 VPC 中提供具有策略控制的私有 IP 端点，并完全避免公共出口；对于更严格的出口控制和一致的 DNS，首选 PSC 端点。

• Private Service Connect（服务生产者和服务使用者）

  • 在生产者项目中通过服务附件发布内部服务，并在使用者项目中通过私有端点使用这些服务。通过 DNS 映射和显式允许策略来控制访问。与 VPC Peering 相比，这改善了隔离性并集中了服务发布。

• VPC Network Peering、Shared VPC 和分段

  • VPC Peering 提供 VPC 之间的低延迟私有连接。它不具有传递性，并且不允许重叠的 IP。可选的自定义路由导入/导出扩展了可达性，但仍不会创建传递路由；需要审慎规划中心辐射型（hub-and-spoke）架构。
  • Shared VPC 将子网集中在宿主项目（host project）中，供服务项目（service projects）使用。这实现了路由、防火墙、NAT 和 LB 的集中管理，同时将每个应用的 IAM 委托出去。结合分层防火墙和安全标记（secure tags）进行分段。
  • Network Connectivity Center (NCC) 提供一个中心（hub）来编排分支（spokes）（VPN、Interconnect、路由器设备、VPC 分支），并一致地管理企业 WAN 拓扑。

• Cloud VPN、Cloud Interconnect 和 BGP

  • Cloud VPN：使用具有动态路由（BGP）的 HA VPN 以实现高可用性和自动路由故障切换。如果可能，为每个对等体（peer）通过独立的 Cloud VPN 接口和不同的本地设备/链路构建两个隧道。
  • Cloud Interconnect：Dedicated Interconnect 提供私有的 10–100 Gbps 链路；Partner Interconnect 使用服务提供商。为实现弹性，请在不同的边缘可用性域中部署冗余的互连，并在支持的情况下将 BFD 与 BGP 结合使用。
  • 故障域：按区域、可用区、设备和提供商进行隔离。定期测试故障切换；非对称路径可能会破坏本地的状态化防火墙。

• 示例

  • gcloud compute routers create corp-router –region=us-central1 –network=prod-net –asn=64514
  • gcloud compute routers nats create nat-us-central1 –router=corp-router –nat-all-subnet-ip-ranges –auto-allocate-nat-external-ips
  • gcloud compute vpn-gateways create ha-gw –region=us-central1 –network=prod-net

可观测性与故障排查

• Connectivity Tests

  • 模拟并验证跨 VPC、本地环境（通过混合连接）和负载均衡器的源与目标之间的可达性。该工具在生产变更前评估路由、防火墙规则和配置，以定位丢包或流量路由错误。
  • 示例：gcloud beta network-management connectivity-tests create test-ilb –source-ip=10.10.1.5 –destination-ip=10.30.4.10 –protocol=TCP –destination-port=80 –project=my-proj

• VPC Flow Logs

  • 在子网级别启用，以实时洞察五元组流、字节数、丢包和延迟。可导出到 Cloud Logging、Pub/Sub 或 BigQuery 进行分析。调整采样率和元数据级别以控制成本。
  • 用例：验证防火墙有效性、检测数据外泄、容量规划和 SLO 监控。

• Packet Mirroring

  • 将 VM 或 GKE 流量镜像到收集器端点，以进行深度包检测（IDS）。可按子网、标签或实例来限定镜像范围。需了解其性能开销，并确保收集器能处理镜像流量。当需要原始报头时，避免镜像 NAT 转换后的流量。

• 常见诊断模式

  • 黑洞：路由存在，但返回路径被防火墙或非对称路由阻塞；使用 Connectivity Tests 和双方的流日志进行验证。
  • 健康检查失败：确认防火墙允许来自健康检查器的流量，且后端在正确端口上侦听；从同一子网内的 VM 进行本地测试。
  • NAT 耗尽：查找原因为“no available NAT ports”的被拒绝流；增加更多 NAT IP 或减少每台 VM 的端口上限。

实践问题场景

Acme Retail 运营一个多区域电子商务平台，该平台包含私有后端、公共 Web 入口和本地 ERP 系统。他们必须对工作负载进行分段，为 Google API 提供私有出站，实现所有区域的混合可达性，并在保持可观测性的同时加固安全性。

1. 创建一个自定义模式的 Shared VPC 以实现集中控制

• gcloud compute networks create acme-net –subnet-mode=custom
• 理由：自定义模式避免了自动分配的 CIDR，从而可以进行审慎的 IP 规划。Shared VPC 将路由、防火墙和 NAT 集中在宿主项目中，同时允许服务项目安全地进行部署。

2. 规划并创建带有 GKE 次要地址范围的子网

• gcloud compute networks subnets create web-us –region=us-central1 –network=acme-net –range=10.10.0.0/20 –secondary-range=pods=10.20.0.0/16,svcs=10.21.0.0/20
• 理由：不重叠的主要和次要地址范围可防止未来的对等连接冲突，并允许 GKE 使用别名 IP，避免 IP 耗尽。

3. 将 VPC 动态路由设置为全局模式并部署 Cloud Router

• gcloud compute networks update acme-net –bgp-routing-mode=global
• gcloud compute routers create hub-uc1 –region=us-central1 –network=acme-net –asn=64514
• 理由：全局模式使通过 BGP 学到的本地路由可在所有区域使用，从而简化了混合可达性和故障切换。

4. 建立到本地环境的 HA VPN 并通告子网

• 跨多个不同的本地设备创建两个 HA VPN 隧道。使用 BGP 交换前缀并实现平滑故障切换。
• 理由：双隧道消除了单点故障；在维护或中断期间，BGP 能快速收敛路由。

5. 部署 Cloud NAT 以实现私有出站，并为 Google API 部署 PSC

• gcloud compute routers nats create nat-uc1 –router=hub-uc1 –nat-all-subnet-ip-ranges –auto-allocate-nat-external-ips
• 为 Google API 创建 Private Service Connect 端点，并更新私有 DNS 以将 API 端点映射到 PSC。
• 理由：NAT 允许在没有外部 VM IP 的情况下访问互联网；PSC 将 API 流量保留在私有 IP 上，并置于明确的策略控制之下，从而消除了公共出站路径。

6. 前端使用全局 External HTTP(S) Load Balancer；内部服务使用 Internal HTTP(S)

• 创建一个全局外部 HTTP(S) LB，使用托管证书，其后端服务指向 NEG 后端。
• 为服务到服务的流量创建区域性 Internal HTTP(S) LB，并在微服务之间使用 mTLS。
• 理由：全局代理 LB 提供任播（anycast）、自动扩缩和 CDN 功能；内部 L7 LB 为东西向流量提供丰富的路由和安全功能。

7. 实施分层防火墙策略和基于工作负载身份的目标定位

• 附加一个组织级别的策略，拒绝来自互联网对管理端口的访问；仅允许来自 LB 健康检查源的流量。
• 创建针对服务账号的 VPC 规则，以实现层级间的最小权限访问；使用安全标签进行动态分段。
• 理由：分层结构可集中实施安全护栏；基于身份的目标定位可防止标签欺骗并简化自动化。

8. 配置具有分离水平（split-horizon）和转发功能的 Cloud DNS

• 为 Web VIP 创建公共区域 acme.com，并为映射到 ILB 的内部服务名称创建私有区域 acme.com。
• 配置到本地 DNS 的出站转发，以及允许本地环境解析私有区域的入站转发。
• 理由：分离水平可防止数据泄露，并确保根据源网络进行正确的名称解析；转发功能集成了旧有的命名空间。

9. 使用 Connectivity Tests、流日志和数据包镜像以获得可见性

• 为关键路径（用户到 Web LB、Web 到内部服务、服务到本地 ERP）创建测试。
• 在子网上启用流日志；导出到 BigQuery 进行趋势分析。在事件响应期间临时启用数据包镜像。
• 理由：主动验证和遥测数据可缩短 MTTR，揭示配置错误，并提供容量洞察。

10. 记录并测试故障场景

• 模拟 VPN 隧道、区域和后端 MIG 的丢失。验证 BGP 故障切换、LB 健康检查移除和 DNS 的正确性。
• 理由：定期的故障演练（game days）可以验证关于冗余的假设，并在配置漂移导致中断前将其暴露出来。

← 容器、应用托管和无服务器平台 · 所有领域 · 存储、数据库和数据服务 →

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

浏览 Google →