Google PCNE: VPC 架构、子网和地址规划 — 学习指南

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

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

概览

Virtual Private Cloud (VPC) 是一个全球性的、逻辑隔离的网络，它跨越所有 Google Cloud 区域。子网是 VPC 内的区域级构造，其 IP 范围为 Compute Engine、GKE 和其他资源提供支持。一个健全的 VPC 架构需要在地址效率、增长和运营控制之间取得平衡，同时确保项目内和项目间工作负载以及到 Google API 的连接具有低延迟和成本效益。

VPC 范围、子网架构和模式

• 全球级 VPC，区域级子网

  • 单个 VPC 跨越所有区域。子网按区域创建，并定义主 IPv4 CIDR 和可选的次要范围。实例从区域子网接收 IP，但默认情况下可以在同一 VPC 内跨区域进行私密通信。
  • 动态路由模式
    • 区域级：Cloud Router 仅与其所在区域的子网交换路由。
    • 全球级：一个区域中的 Cloud Router 会向所有区域通告学习到的路由。当需要多区域工作负载或高可用性 (HA) 出口时，首选全球级模式。

• 自动模式 vs 自定义模式

  • 自动模式为每个区域创建一个具有预分配 CIDR 的子网。它对于快速入门很方便，但在规模化时缺乏灵活性。它可以转换为自定义模式；此转换是单向的。
  • 自定义模式提供了对子网创建和 CIDR 选择的完全控制。这是生产环境地址规划、Shared VPC、对等互连和未来增长的推荐模式。
  • 迁移说明：将自动模式转换为自定义模式后，那些假定使用自动模式子网的工件或模板通常会失败，直到明确更新以引用自定义子网为止。

• 子网的不可变性与增长

  • 子网的区域是不可变的；您无法在区域之间移动子网。
  • 主 IPv4 范围可以就地扩展（扩大前缀），但不能缩小，并且必须在整个 VPC 及任何连接的网络中保持不重叠。
  • 次要范围可以添加或删除（取决于使用情况），但也必须保持不重叠。

地址规划：主/次要范围、别名 IP、IPv6 和私有空间

• 主 IPv4 和次要 IPv4 范围

  • 主范围：分配虚拟机接口地址（默认为 nic0）。它会创建一个系统生成的子网路由，并用于大多数内部通信。
  • 次要范围：将额外的 CIDR 与子网关联，是 VPC 原生 GKE 集群所必需的。为次要范围生成的系统路由允许 Pod 和 Service 之间的东西向连接。

• 别名 IP

  • 别名 IP 允许一个虚拟机网络接口控制器 (NIC) 拥有来自子网主范围或次要范围的多个 IP，从而实现基于 IP 的紧密策略、VPC 原生 GKE 的 Pod IP 以及高效的 IP 利用率。
  • 对于 GKE，规划大型连续的次要 CIDR，以最大限度地减少碎片和未来的调整需求。例如：对于拥有 100 个节点、每个节点 200 个 Pod 和 1500 个 Service 的场景，为 Pod 分配至少 /17 的次要范围，为 Service 分配 /21 的范围，以留出余量。

• 私有 RFC 1918 设计和 IP 管理

  • 在所有当前和计划中的 VPC、本地环境以及合作伙伴网络中选择不重叠的地址块。为每个环境保留大的父块，然后按区域和功能划分可预测的子块。
  • 为增长、次要范围、迁移缓冲区（临时的双栈/双重 NAT）和基础架构端点（ILB VIP、PSC 端点）预留容量。
  • 如果可能需要与合作伙伴连接，请避免使用最常见的企业地址块；或者使用 NAT 进行分段以解决冲突。

• IPv6 规划

  • 外部 IPv6：在全局负载均衡器上使用全球外部 IPv6 地址，以实现客户端访问和任播可达性。
  • 内部 IPv6：在可用时，启用双栈子网为虚拟机分配内部 IPv6，并相应调整防火墙规则。规划 DNS AAAA 记录并确保与 IPv4 策略的对等性。
  • 保留 IPv4 用于云内控制和第三方集成；通过负载均衡器和双栈子网逐步引入 IPv6。

路由：隐式路由、自定义路由、优先级、标记和下一跳

• 隐式（系统生成）路由

  • 子网路由：每个主子网和每个次要范围各有一条，目的地等于 CIDR，下一跳是子网本身。
  • 默认路由：默认创建一条 0.0.0.0/0 指向默认互联网网关的路由；出站到互联网需要外部 IP 或 NAT。

• 自定义路由和选择逻辑

  • 最长前缀匹配优先。如果多条路由具有相同的前缀长度，则优先级数值最低者优先（默认优先级为 1000）。
  • 标记和服务帐号
    • 没有标记的路由适用于所有虚拟机。带标记范围的路由仅适用于具有匹配网络标记的实例。
    • 基于身份的防火墙规则可以匹配服务帐号；在可能的情况下，使用它们进行比标记更精细的控制。

• 下一跳

  • 自定义路由支持的下一跳包括：
    • 默认互联网网关（0.0.0.0/0 或更具体的出站前缀）
    • 实例（需要启用 IP 转发才能为其他实例路由流量；用于虚拟设备）
    • Cloud VPN 隧道（静态路由）
    • 区域级内部负载均衡器作为下一跳（用于可扩展的设备模式）
  • 您不能将下一跳设置为 VPC 对等互连连接；对等互连会自行处理路由交换。

• 流量导向示例（虚拟设备）

  • 创建一条比子网路由更具体的路由，其下一跳指向一个启用了 IP 转发的实例，并通过源虚拟机上的标记来限定范围。

  • 示例：

undefined

• 在没有外部 IP 的情况下出站至 Google API
  • 方案 1：在子网上启用 Private Google Access (PGA)，然后如有必要，为 Google API VIP 添加指向默认互联网网关的自定义路由，以绕过第三方默认出站路径。
  • 方案 2：将 Cloud NAT 与 PGA 结合使用，为私有虚拟机提供到 Google 服务的出站访问。
  • 方案 3：使用 Private Service Connect 连接到 Google API 以实现无需互联网的访问；流量保留在 Google 网络上，并使用您 VPC 中的一个私有 RFC1918 端点。
  • 如需进行受限访问，请将客户端指向受限的 Google API VIP，并强制执行出站控制。

共享 VPC、对等互连、委派管理和服务帐号

• 共享 VPC

  • 宿主项目拥有一个或多个集中管理的 VPC 和子网。服务项目将工作负载附加到选定的共享子网上。
  • 委派管理
    • 共享 VPC 管理员配置连接和子网共享。
    • 网络管理员在宿主项目中管理路由、子网和防火墙。
    • 服务项目中的项目级 IAM 控制工作负载的部署；您可以仅共享必要的子网以限制爆炸半径和路由可见性。
  • 服务帐号
    • 优先使用基于服务帐号的防火墙策略，以实现跨团队的、确定性的、由身份驱动的控制。
    • 为每个层级和环境使用专用的服务帐号，并为数据访问授予最低权限的角色（例如，为读取 Cloud Storage 的服务帐号授予 Storage Object Viewer 角色）。

• VPC 网络对等互连

  • 限制
    • 非传递性：A↔B 和 B↔C 并不意味着 A↔C。如果需要，构建全网状拓扑。
    • 对等互连的网络之间 IP 范围不能重叠。
    • 路由交换仅限于子网路由（包括次要范围）；不支持通过对等互连进行下一跳导向。
  • 当不同的 VPC 必须保持管理上的独立性时，使用对等互连可实现低延迟、私有的组织内部连接，且运维开销最小。

• 混合连接

  • 在共享 VPC 宿主项目中集中部署 Dedicated Interconnect 和 Cloud Router，以便与各部门的服务项目共享高容量连接。
  • 使用 HA VLAN 连接、多样化的边缘位置、双 Cloud Router 和全球动态路由，以实现弹性并将路由传播到所有需要的区域。

运维：扩展、HA、专用访问、验证和问题排查

• 子网扩展和迁移约束

  • 当子网容量接近耗尽时，进行原地扩展；验证所有连接的网络以确保地址范围不重叠，并确保依赖的 GKE 次要范围仍然足够。
  • 如果地址范围在不同组织或合作伙伴之间存在重叠，请采用 NAT 或分阶段重新编号。您不能对等互连重叠的 VPC，也不能安装重叠的动态路由。

• 区域性部署和高可用性

  • 将子网放置在最接近用户和数据的区域。对于跨大西洋的用户群体，一个在 us-east1 和 europe-west1 拥有区域子网的单一 VPC 可提供直接的专用连接，实现最佳延迟，并且 VPC 内部无出站流量费用。
  • 将工作负载分布到多个可用区；使用区域级代管实例组和区域级内部/外部负载均衡器以实现可用区故障容错。
  • 对于混合云，在每个区域或边缘位置部署双 Cloud Routers 和连接；在支持的情况下启用 BFD；使用全局动态路由进行故障切换。

• 专用 Google 访问和受限端点

  • 在托管无外部 IP 实例的子网上启用 PGA。
  • 为阻止常规互联网出站流量同时允许访问 Google API：
    • 将默认流量路由到您的 NGFW。
    • 为 Google API VIP 添加指向默认互联网网关的更具体静态路由，或为 Google API 部署 PSC 端点。
  • 示例：
    • gcloud compute networks subnets update app-subnet –region=us-central1 –enable-private-ip-google-access

• 拓扑验证和问题排查

  • 使用 Network Intelligence Center：
    • 使用 Connectivity Tests 验证可达性，并模拟路由、防火墙和网关决策。
    • 使用 Performance Dashboard 和 Topology 可视化路径和健康状况。
  • 日志和遥测：
    • 使用 VPC Flow Logs 观察每个接口的允许/拒绝和延迟情况。
    • 使用 Firewall Rules Logging 确认规则匹配。
    • 针对无外部 IP 的出站问题，使用 Cloud NAT 日志和健康状况。
    • 使用负载均衡器和健康检查日志了解后端的就绪状态。
  • CLI 检查：
    • 使用 gcloud compute routes list 和 gcloud compute firewall-rules list 确认生效的策略。
    • 从测试虚拟机执行 traceroute 和 curl；在需要深度检查时使用 packet mirroring。

实际问题场景

Acme 零售集团需要一个多区域、低延迟的 Google Cloud 网络，该网络具有集中控制能力，能让私有实例在无互联网访问的情况下访问 Google API，并能在不需要通信的部门之间实现严格隔离。一些团队运行着具有高 Pod 密度的 GKE。Acme 还通过第三方防火墙引导常规出站流量，但希望 Google API 流量绕过该防火墙。

1. 在一个宿主项目中以自定义模式构建一个启用了全局动态路由的单一 Shared VPC，并在 us-east1 和 europe-west1 中创建区域子网，同时为 GKE 预留次要范围。

• 理由：单一 VPC 通过 RFC1918 地址提供私有的、零成本的跨区域连接，以实现最佳效率。自定义模式和全局动态路由支持精确的 IP 规划和多区域路由传播。

2. 仅将所需的特定子网共享给每个部门的服务项目；创建三个服务项目（销售、财务、市场），并仅向每个项目暴露其所需的子网。

• 理由：按子网共享可以限制爆炸半径和路由暴露，在实现集中运维的同时强制隔离。委托的 IAM 允许中央网络管理员管理防火墙和路由，而应用团队则可以独立部署工作负载。

3. 对于必须通信的部门，将其专用 VPC 进行对等互连，或将它们放置在同一个 Shared VPC 子网中；对于需要隔离的部门，不要进行对等互连，也不要共享重叠的子网。

• 理由：对等互连以最小的运维开销提供低延迟的专用连接。非传递性要求仅在需要时建立显式的网状连接，这默认保留了隔离性。

4. 在所有共享子网上启用 Private Google Access，并为 Google API 部署 Private Service Connect 端点；保留指向第三方防火墙的默认路由，并为 Google API VIP 添加指向默认互联网网关的更具体静态路由。

• 理由：PGA 和 PSC 使得私有虚拟机可以在没有互联网访问的情况下使用 API。更具体的路由确保 API 流量绕过 NGFW，而其他非 Google 的互联网出站流量则继续通过检查路径。

5. 分配具有增长空间的主要和次要 CIDR：对于 GKE，为每个繁忙区域规划一个 Pod 次要范围（例如 /17）和一个 Services 次要范围（/21）；为 Pod 和 Service 使用别名 IP，并创建绑定到这些范围的 VPC 原生集群。

• 理由：次要范围和别名 IP 可以防止节点 IP 耗尽，并允许密集的调度。为未来需求规划容量可以避免破坏性的规模调整和次要范围的重新编号。

6. 为混合云和设备流量实施 HA：根据需要部署双 Cloud Routers 和 HA VPN 或 Interconnect；当需要通过虚拟设备引导流量时，使用更具体的自定义路由，其下一跳设置为区域内部负载均衡器或启用了 IP 转发并受标签范围限制的实例。

• 理由：边缘的 HA 确保了故障期间的连续性。通过标签限定路由范围可以避免意外的流量发夹弯，并只让选定的实例遍历设备路径。

7. 使用 Network Intelligence Center 的 Connectivity Tests、VPC Flow Logs 和 Firewall Rules Logging 进行验证和操作；使用服务账号强制执行基于身份的防火墙策略，并维护 IPAM 记录，为每个区域和功能保留缓冲空间。

• 理由：主动验证可以防止变更期间发生中断。基于身份的策略比仅基于标签的方法更健壮。规范的 IPAM 可以防止地址重叠，这种重叠会阻止对等互连或抑制学习到的路由。

所有领域 · 防火墙策略、Cloud Armor 和网络安全 →

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

浏览 Google →