手册

为大规模或混合云部署规划 IP 地址。

→使用自定义模式 VPC。分配不重叠的 RFC 1918 CIDR 块（例如 172.16.0.0/12），以避免与本地环境（通常为 10.0.0.0/8）冲突。将 100.64.0.0/10 用于 GKE Pod 的辅助范围。

原因: 避免与本地环境发生 IP 冲突，以便未来进行混合连接，并提供对地址空间的完全控制，这对于扩展和避免昂贵的重新 IP 规划至关重要。

参考↗

为多个租户/环境（开发、生产）提供网络隔离，同时集中管理网络和共享服务。

→使用 Shared VPC。宿主项目包含 VPC、子网、防火墙和互连。租户/环境是附加到宿主项目的服务项目。

原因: 将网络管理集中到宿主项目中，同时将资源管理委托给服务项目。与组织内许多项目使用 VPC peering 相比，更具可扩展性和可管理性。

参考↗

使用 VPC-native 网络为大型 GKE 集群规划 IP 地址。

→在自定义模式 VPC 中，规划三个 CIDR 范围：一个用于节点的primary 范围，一个用于 Pod 的 secondary 范围，以及一个用于 Services 的范围。为了扩展，请使用不连续的 multi-pod CIDR。

原因: VPC-native 网络要求 Pod 和 Services 具有专用、不重叠的 secondary 范围。适当的规模规划可防止 IP 耗尽，这是大型集群中常见且具有破坏性的问题。

参考↗

没有外部 IP 的 VM 需要访问 Google Cloud API（例如 Cloud Storage、BigQuery）。

→在子网上启用 Private Google Access。可以选择配置 DNS 将 `*.googleapis.com` 解析为 `restricted.googleapis.com` (199.36.153.4/30) 以强制执行 VPC-SC。

原因: 无需 VM 上的公共 IP，即可通过 Google 的内部网络将流量路由到 Google API。使用 `restricted.googleapis.com` 增加了数据泄露防护层。

参考↗

为 VPC 拥有重叠 IP 范围的消费者（合作伙伴、其他业务部门）提供对其 VPC 中服务的私有访问。

→使用 Private Service Connect (PSC) 服务附件发布服务（通过 Internal Load Balancer）。消费者在其 VPC 中使用其自身范围内的 IP 创建 PSC 端点。

原因: PSC 解耦了生产者和消费者网络，使用 NAT 处理重叠的 IP。它提供安全的服务级访问，而不是像 VPC peering 那样提供完整的网络连接。

参考↗

以中心辐射型拓扑连接大量（50+）VPC 和/或本地站点，以实现集中管理和连接。

→使用 Network Connectivity Center。配置中心并将 VPC 作为 VPC 辐条连接，将本地连接（VPN/Interconnect）作为混合辐条连接。

原因: NCC 是 Google 针对大规模中心辐射型拓扑的托管解决方案，简化了路由管理，并超越了 VPC peering 的 25 个对等体限制。

部署 GKE 集群，其中节点和控制平面不具有公共 IP 地址，以增强安全性。

→创建 Private GKE 集群。这将只为节点分配内部 IP，并为控制平面创建私有端点。配置授权网络以限制控制平面访问。

原因: 私有集群将控制平面和节点从公共互联网中移除，显著减少了攻击面。所有管理和工作负载流量都保留在私有网络上。

无服务器工作负载 (Cloud Run, Functions) 需要访问 VPC 内的资源（例如 Cloud SQL, Memorystore）。

→在目标 VPC 中创建 Serverless VPC Access 连接器。配置无服务器服务以使用此连接器进行出站流量。

原因: 该连接器充当代理，允许无服务器服务（在 Google 托管环境中运行）使用内部 IP 将流量发送到客户管理的 VPC。

某个应用（例如 HPC、金融交易）要求一组 VM 之间具有绝对最低的网络延迟。

→创建紧凑型放置政策并将其应用于 VM。使用具有 Tier_1 网络的机器类型。

原因: 将 VM colocating 在同一网络机架中可最大限度地减少网络跳数和物理距离，与标准 VM 放置相比显著降低延迟。

为微服务实施零信任安全模型，要求强大的身份、加密通信 (mTLS) 和细粒度授权。

→部署 Anthos Service Mesh。为所有服务间通信启用自动 mTLS。使用 `AuthorizationPolicy` 资源定义允许的通信。

原因: 服务网格将安全性与底层网络解耦，提供工作负载身份、透明 mTLS 和 L7 授权，这些是零信任架构的核心租户。

没有公共 IP 的工作负载（VM、GKE Pod）需要一个稳定、可预测的源 IP，以便出站连接到使用允许列表的外部 API。

→部署 Cloud NAT。使用“手动 NAT IP 分配”选项，并将预留的静态外部 IP 地址分配给 NAT 网关。

原因: 手动分配的 Cloud NAT 提供共享的静态出站 IP 池。这使得工作负载与 IP 解耦，允许扩展而无需更新外部允许列表。

VPC peering 已建立，但 VM 无法在对等 VPC 之间通信。

→验证 *两个* VPC 中的防火墙规则都允许来自另一个 VPC IP 范围的入站流量。对等连接只建立路由；它不会隐式创建防火墙允许规则。

原因: 一个常见错误是假设对等连接会打开防火墙端口。隐式的拒绝所有入站规则会阻止流量，直到创建明确的允许规则。

在 Shared VPC 中，仅授予团队/服务项目使用特定子网而非整个 VPC 的权限。

→在宿主项目中，在子网级资源上授予 `compute.networkUser` IAM 角色给服务项目的身份（例如服务账号、群组）。

原因: IAM 角色可以限定到特定资源。在子网级别应用 `compute.networkUser` 强制执行最小权限，只允许使用该子网。

为 Compute Engine 上的多层应用（例如 web、app、db）实施微细分。

→根据其层级（例如 `web-server`）为 VM 分配网络标签。创建使用这些标签作为源和目标指定器的防火墙规则。

原因: 标签提供了一种灵活、可扩展的替代 IP 地址规则的方法。防火墙策略独立于层级中 VM 的数量或 IP。

捕获流量元数据以进行合规性/审计，同时最大限度地减少日志量和存储成本。

→启用 VPC Flow Logs，并设置更长的聚合间隔（例如 10 分钟）、更低的采样率（例如 0.5），以及元数据过滤以排除不需要的字段。

原因: 默认设置会生成大量数据。调整这些参数可显著降低成本，同时仍为大多数审计用例提供足够的可见性。

通过低延迟交付全球应用，将用户路由到最近的健康后端并自动故障转移。

→使用 Global External Application Load Balancer（对于非 HTTP 则使用 TCP/SSL Proxy LB）。在多个区域中配置后端服务/NEGs。使用 Premium Tier 网络。

原因: 负载均衡器的 anycast IP 将用户引导到最近的 Google 边缘 PoP。然后流量通过 Google 的私有骨干网传输到最近的健康后端，以实现最佳性能。

参考↗

根据 URL 路径或主机名路由内部流量，带有 SSL 终止，只能在 VPC 内部或从本地访问。

→使用 Regional Internal Application Load Balancer。配置 URL map 以根据主机/路径规则导向流量。需要一个 proxy-only 子网。

原因: 这是 Google 托管的 L7 内部负载均衡器。它提供了 L4 Internal Passthrough Network LB 不具备的高级路由功能。

使用 Cloud CDN 缓存和提供私有或用户特定的内容，而无需将其公开。

→在私有后端（例如 GCS bucket）上启用 Cloud CDN。在您的应用中生成 Cloud CDN Signed URLs 或 Signed Cookies，以授予用户临时、经过身份验证的访问权限。

原因: Signed URLs/Cookies 提供了一个安全令牌，Cloud CDN 在提供缓存对象之前会对其进行验证，从而利用边缘缓存同时保持严格的访问控制。

在本地网络和 GCP VPC 之间启用双向 DNS 解析。

→1) 本地解析 GCP：创建 Cloud DNS 入站服务器策略。配置本地 DNS 将请求转发到入站转发器 IP。 2) GCP 解析本地：创建指向本地 DNS 服务器的 Cloud DNS 转发区。

原因: 这种标准的双部分配置为混合环境提供了无缝、私有的名称解析，这是应用互操作性的关键组成部分。

由于不必要的 URL 变体（例如跟踪参数），Cloud CDN 缓存命中率较低。

→为后端服务配置自定义缓存键策略。从缓存键中排除非必要的查询参数、cookies 和 headers。

原因: 默认情况下，完整 URL 是缓存键。通过排除不相关参数来规范化键可以防止缓存碎片化并显著提高命中率。

将 DNS 名称解析为内部客户端的内部 IP 和外部客户端的公共 IP。

→为域创建 Cloud DNS 私有区域（对您的 VPC 可见），其中包含内部 IP 记录。创建匹配的 Cloud DNS 公共区域，其中包含公共 IP 记录。

原因: Cloud DNS 自动向授权 VPC 内的客户端提供来自私有区域的响应，并向其他所有人提供公共区域的响应。

一个区域的内部应用需要被其他区域的客户端（VM、本地）访问。

→在 Internal TCP/UDP Load Balancer 或 Internal Application Load Balancer 的转发规则上启用“Global Access”选项。

原因: 默认情况下，内部 LB 是区域性的。Global Access 使它们可以从 VPC 网络中的任何区域访问，从而简化了多区域内部服务架构。

在本地环境和 GCP 之间建立高可用性（99.99% SLA）、高带宽（10G+）的连接。

→至少提供四条 Dedicated Interconnect 连接，两条在一个 metro，两条在另一个 metro，每个 metro 对位于不同的边缘可用性域中。配置 BGP。

原因: 跨独立都会区和故障域（边缘可用性域）的冗余是实现 99.99% SLA 所必需的。

参考↗

需要加密、可靠（99.9% 或 99.99% SLA）且可快速部署的混合连接，带宽适中（< 6 Gbps）。

→使用带 BGP 的 HA VPN 进行动态路由。对于 99.99% SLA，使用两个 HA VPN 网关。对于 99.9% SLA，使用单个网关和两条隧道。

原因: HA VPN 比 Interconnect 设置更快，提供强大的 SLA，并为许多用例提供足够的带宽，使其成为非物理连接的默认选择。

为了合规性，加密所有通过 Dedicated 或 Partner Interconnect 链路的流量。

→通过 Interconnect 配置 HA VPN。创建使用 Interconnect 的 VLAN attachments 作为其底层传输的 HA VPN 隧道。

原因: 此模式将 Interconnect 的高带宽和低延迟与 HA VPN 的 IPsec 加密相结合，提供两全其美的优势。

在 GCP 与另一个主要云提供商（AWS、Azure、OCI）之间建立专用、私有、高带宽的连接。

→使用 Cross-Cloud Interconnect。在 Google 网络和另一个云提供商网络之间提供专用物理连接。使用 Cloud Router 配置 BGP。

原因: 提供了云之间直接的、SLA 支持的低延迟路径，避免了公共互联网和 VPN 性能的可变性。

通过 Interconnect 连接到一个 GCP 区域的本地网络需要访问所有其他 GCP 区域中的资源。

→在 VPC 上启用“Global”动态路由模式。Cloud Router 将随后通告 VPC 中所有子网的路由，而不仅仅是其本地区域中的子网。

原因: 全局路由允许单个混合连接点作为进入 Google 整个全球网络的入口，简化了多区域访问。

使用 BGP 影响通过冗余混合连接（VPN/Interconnect）的流量路径选择。

→要影响 GCP 到本地的流量，让本地通告更具体的路由或使用较短的 AS_PATH 作为首选路径。要影响本地到 GCP 的流量，从 Cloud Router 以较低的 MED 值通告作为首选路径。

原因: BGP 路径选择遵循清晰的算法。最长前缀匹配是出站流量的关键，而 MED 影响入站流量决策。

配置主 Dedicated Interconnect 和备用 HA VPN 之间的主动/被动故障转移。

→两者都使用 BGP。在 Cloud Router 上，通过 Interconnect 通告较低基础优先级（例如 100）的路由，并通过 VPN 通告较高基础优先级（例如 200）的路由。

原因: GCP 优先选择具有较低优先级值（较高偏好）的 BGP 路由。流量使用主 Interconnect。一旦发生故障，其路由将被撤销，备用 VPN 路由将变为活动状态。

防止敏感的 Google Cloud 服务（例如 BigQuery、GCS）中的数据泄露，确保仅从授权网络进行访问。

→实施 VPC Service Controls。围绕包含敏感数据的项目创建服务边界。配置访问级别以定义授权源（IP 范围、设备状态、身份）。

原因: VPC-SC 在 Google 托管服务周围创建虚拟网络边界，即使拥有有效凭据也阻止来自边界外部的访问。这是一个关键的数据治理控制。

参考↗

在整个组织中强制执行一致、不可覆盖的基线防火墙规则，同时允许项目级别的自定义。

→在组织或文件夹级别实施 Hierarchical Firewall Policies。在此处放置关键规则。使用 `goto_next` 操作将评估委托给下级策略。

原因: 分层策略在 VPC 级规则之前进行评估，并且项目所有者无法修改，确保集中治理。`goto_next` 提供了灵活性。

保护 Web 应用免受 OWASP Top 10 漏洞的侵害，并应用基于每个客户端 IP 的速率限制。

→将 Cloud Armor 安全策略附加到 Global External Application LB。应用预配置的 WAF 规则（例如 `sqli-v3.3-stable`）并添加基于速率的规则。

原因: Cloud Armor 提供边缘安全。预配置的 WAF 规则提供托管保护，而基于速率的规则可以缓解 DoS 和暴力攻击。

在 GKE 集群内部，根据标签实施细粒度的 Pod 级别网络安全。

→在 GKE 集群上启用 Network Policy enforcement。创建 Kubernetes `NetworkPolicy` 资源，这些资源使用标签选择器定义 Pod 的入站/出站规则。

原因: Kubernetes NetworkPolicy 是在 Pod 级别实施微细分的本地方式，比在节点级别运行的 VPC 防火墙规则提供更高的粒度。

使用集中式第三方防火墙/NVA 检查所有 VPC 间或 VPC 到互联网的流量。

→创建中心辐射型拓扑。将 NVA 部署在中心 VPC 中。在辐条中配置自定义路由，将流量导向中心的 Internal Load Balancer 作为下一跳。

原因: 此模式强制流量通过中央检查点。ILB 为 NVA 提供了一个稳定、高可用的下一跳 IP。

为用户提供安全、基于身份的零信任访问内部 Web 应用或 VM 的功能，而无需使用 VPN。

→对于 Web 应用，在 External HTTPS LB 后端服务上启用 IAP。对于 SSH/RDP，使用 IAP 进行 TCP forwarding。授予用户适当的 IAP IAM 角色。

原因: IAP 将访问控制从网络边界转移到用户身份，对每个请求进行身份验证和授权。它是 Google BeyondCorp 零信任模型的核心组件。

为 VPC 间或 VPC 到互联网的流量实施威胁防护 (IDS/IPS)，包括恶意软件检测和 TLS inspection。

→使用 Cloud NGFW。将防火墙策略与 VPC 关联，创建带有安全配置文件以进行威胁防护的规则，并可选地启用 TLS inspection。

原因: Cloud NGFW 是 Google 的分布式、托管防火墙服务，提供 Palo Alto Networks 的高级 L7 检查功能，直接集成到 VPC 中。

集中检查、记录和控制所有从 VPC 到互联网的出站流量，以实现安全性和合规性。

→部署 Secure Web Proxy。配置用于 URL 过滤和 TLS inspection 的安全策略。使用自定义路由将流量从子网路由到代理。

原因: 这是 Google 的安全出站托管解决方案，提供 L7 可见性和控制，而无需自行管理代理集群。

快速诊断 GCP 内两个端点之间（例如 VM 到 VM、VM 到 Cloud SQL）的连接故障。

→使用 Network Intelligence Center 的 Connectivity Tests。指定源和目标，它将分析整个配置路径以查找问题。

原因: 这种非侵入式工具提供了对路径的确定性分析，比手动检查更快地找出确切的故障点（防火墙、路由等）。

混合连接上的 BGP 会话间歇性重置（“flapping”）。

→检查 BGP keepalive/hold timer 是否不匹配。如果 timer 在负载下过期，请增加它们（例如 60s keepalive，180s hold）。此外，检查 MTU 设置并启用 BFD。

原因: 不匹配或过于激进的 timer 是 BGP flapping 的常见原因，因为短暂的网络拥塞可能会使 keepalive 数据包延迟超过 hold time。

调查 GCP 区域间流量延迟增加的报告。

→使用 Network Intelligence Center 的 Performance Dashboard 查看所有 GCP zone 对之间的历史和实时延迟和 packet loss 指标。

原因: 此工具直接提供对 Google 骨干网络性能的可见性，有助于区分应用问题和网络基础设施问题。

使用 Cloud NAT 的 VM 遇到间歇性出站连接失败，并且 NAT 日志显示 `OUT_OF_RESOURCES` 丢弃。

→这可能是 NAT 端口耗尽。增加分配的 NAT IP 数量，增加“Minimum ports per VM instance”，和/或启用 Dynamic Port Allocation。

原因: 来自许多 VM 的高连接速率可能会耗尽每个 NAT IP 分配的源端口池。分配更多资源是必需的修复方法。