GCP充值折扣 GCP 谷歌云账号共享 VPC 设置

前言：共享 VPC 这事儿，看着简单，做起来像搬家

在 GCP 的世界里，“共享 VPC”听起来像是把客厅的沙发共享给卧室——大家都能用，但你得先把门锁好、把账算清、还要确保没有人把你家的地毯拿走。尤其当涉及“账号共享”，也就是从一个管理账号（Host）把网络资源提供给其他账号（Service）时，系统的边界会更明确：谁能看、谁能改、谁能用，都有讲究。

本文以“GCP 谷歌云账号共享 VPC 设置”为标题，带你从零到可用，顺便把一些常见踩坑点和排查方法掰开揉碎讲清楚。目标不是让你复制粘贴一堆配置就算完成，而是让你理解每一步的意义——这样出了问题你才知道去哪里找答案。

什么是 Shared VPC：一句话先把概念说透

共享 VPC（Shared VPC）是指：在一个“主机项目”（host project，通常位于 Host 账号或 Host 项目）中创建和管理网络（VPC、子网、路由等），然后把这些网络共享给其他项目（service projects，对应参与共享的账号/项目）。

换句话说：网络“住”在 Host，业务工作负载“住”在 Service，但它们可以通过被授权的方式使用同一套网络。

账号共享的常见架构：你到底在共享什么

在多账号场景里，通常你会遇到以下两类角色：

• Host 账号/项目：持有 VPC 网络资源的项目。它负责创建 VPC、子网、路由、防火墙（看你怎么设计）。
• Service 账号/项目：运行业务实例（VM、GKE 节点等）的项目。它们通过授权使用 Host 的网络。

注意：共享 VPC 并不等于“随便谁都能用”。它是一个“资源所有权清晰 + 访问控制严格”的机制。权限、组织层级、项目级授权都会影响最终效果。

共享 VPC 设置前的准备工作：别急着点开控制台

如果你直接上来就配置，很容易出现“配置做了但连不上/权限不生效/路由不通”。为了让你少走弯路，建议先准备这些信息：

1. 明确 Host 与 Service 的层级关系

GCP充值折扣 通常 Shared VPC 要求 Host 与 Service 在同一个组织（Organization）下，或者至少能在你能进行资源共享的组织/资源容器范围内完成授权。你至少要知道：

• Host 项目在哪个组织、哪一层级（Folder/Organization）
• Service 项目在哪个组织、哪一层级

如果你不确定，先查一下资源管理层级。因为后面授权往往跟组织策略有关，层级错了就像拿错钥匙开门：你拧得再用力也没用。

2. 规划网络：子网、区域、IP 段

共享 VPC 的网络规划要尽量在 Host 侧一次想清楚，避免后续频繁扩展或修改。例如：

• VPC 的名称与用途（例如：prod、dev 区分）
• 子网划分方式（按区域、按环境、按业务线）
• IP 地址段（避免冲突，尤其是多环境或多团队同时用）
• 是否需要多区域子网、是否需要私有谷歌访问、是否需要特定路由

IP 规划这件事，有一个现实：你以后可能会后悔。所以尽量提前规划好，至少把不会变动的部分先定下来。

3. 准备 IAM 权限与角色

共享 VPC 的授权需要用到特定权限，常见的包括：

• Host 项目：允许被授权服务项目使用共享 VPC 的能力
• Service 项目：允许创建实例/子资源并使用被共享网络的权限

此外，还要考虑你们是否有统一的身份管理（例如群组、SSO、服务账号）。权限没对上，后面一切都可能卡在“看起来都配置了，但就是用不了”。

实际配置步骤：从 Host 到 Service，一步步落地

下面按流程给出一个典型设置思路。你可以把它当成“做作业的标准步骤”，照着来不会太离谱。

步骤一：在 Host 项目启用共享 VPC

首先你需要在 Host 项目开启共享 VPC 功能，让 Host 成为“共享网络的提供者”。

• 登录 GCP 控制台
• 选择 Host 项目
• 进入共享 VPC 相关页面
• 启用“此项目作为主机项目（host project）”

启用后，这个 Host 项目会出现与共享相关的配置入口，比如子网共享、服务项目授权等。

小提示：这里不一定叫同一个界面名，具体 UI 可能随控制台更新略有差异。但核心逻辑不变：把 Host 项目标记成可以共享网络的“主机项目”。

步骤二：在 Host 项目创建 VPC 与子网

共享 VPC 的网络资源一般由 Host 管理。你需要创建（或使用现有）VPC 与子网。

• 创建 VPC
• 创建子网（注意区域；如果你要在多个区域跑实例，就要相应创建子网）
• 根据需要配置路由与防火墙策略（防火墙规则可在 Host 或按你们治理方式设置）

如果你已有 VPC，也可以沿用，只要你把子网纳入共享范围。

步骤三：把 Host 的网络共享给 Service 项目（授权）

当 Host 的网络准备好后，就要把它共享给 Service 项目。这个环节通常会要求你做授权配置，确保 Service 项目被允许使用 Host 的子网。

• 在 Host 项目的共享 VPC 配置页面找到“服务项目（service projects）”相关设置
• 添加 Service 项目为共享受让方
• 选择授权的网络/子网（有些场景是以网络或以子网粒度控制）

这一步很关键。很多人犯的错是：只在 Service 侧以为自己“有权限”就行了，结果 Host 侧根本没有把子网共享出去。权限没有通路，再怎么努力都是空话。

步骤四：在 Service 项目授予必要的网络使用权限（IAM）

共享 VPC 的授权不仅仅是“Host 把网络给你”，还需要在 IAM 层面确认 Service 项目里创建资源的主体（用户或服务账号）有权限。

一般你要确保：

• Service 项目中用于部署的账号/服务账号具备创建实例、使用子网、使用网络的权限
• 与共享 VPC 相关的权限（例如网络使用者角色）已经绑定到正确的身份

简单说：Host 侧授权是“给你门票”，Service 侧 IAM 是“给你进场权限”。两者缺一不可。

步骤五：在 Service 项目创建资源并指定网络

当 Host 与 Service 的授权都搞定后，你就可以在 Service 项目里创建实例/集群等资源，并让它们使用被共享的 VPC 与子网。

例如创建 VM 时：

• 选择网络：应该能看到来自 Host 的共享 VPC
• 选择子网：通常可在指定区域的共享子网中选择

如果你在下拉列表里看不到共享 VPC/子网，那大概率是授权没通，或者 IAM 没到位，或者你用的不是正确的区域/子网条件。

步骤六：路由、防火墙与连通性检查：让它“能跑起来”，别只“能建起来”

共享 VPC 配置做完后，真正让人头大的往往是“连不通”。这部分你要做系统检查：

• 防火墙规则：是否允许入站/出站到你预期的端口与源地址
• 路由规则：是否存在到目标网络的正确路由（尤其是你还接了 VPN、Interconnect、或有多网段需求）
• 启用/禁用的网络特性：例如是否需要私有谷歌访问（Private Google Access）、是否需要 NAT、是否有自定义路由

一个常见现象是：你在控制台能创建 VM，但业务访问不通。此时优先怀疑防火墙和路由，而不是一开始就怀疑“共享 VPC 没生效”。共享 VPC 多半是生效的，只是网络策略没按你想的来。

常见坑位清单：提前绕开那些“看起来像玄学”的问题

坑 1：Host 和 Service 不在同一个组织/资源容器范围

共享 VPC 的授权与可见性通常受组织层级影响。如果你的 Host 与 Service 在不相容的层级，可能出现：看得到某些配置项，但真正授权失败，或者授权后子网不可用。

解决思路：

• 核对 Organization 与 Folder 层级
• 检查是否存在组织政策限制（例如限制共享或限制网络配置）

坑 2：Host 已共享，但 Service 项目创建不到网络/子网

这常常是 IAM 的锅。你以为“共享了就能用”，但用户或服务账号缺少网络使用权限时，会导致下拉列表不可见或创建失败。

GCP充值折扣 解决思路：

• 确认你使用的身份（用户/服务账号）是否已绑定正确角色
• 确认作用域是 Service 项目还是更大范围
• 核对是否用了不同的身份进行创建与鉴权

坑 3：防火墙规则策略不一致，导致业务“建好了但不通”

如果你们团队采用“Host 管防火墙、Service 管应用安全组/标签”的治理方式，那么必须保证防火墙规则能覆盖 Service 侧实例。

解决思路：

• 检查防火墙规则的目标（target tags/target service accounts/目标网络等）
• 确认实例的网络标签或服务账号与规则匹配
• 必要时先用最小化可用规则验证连通性

坑 4：IP 段规划冲突，或与其他网络互通段发生重叠

共享 VPC 最大的魅力之一是“统一网络治理”。但魅力背后是现实：IP 冲突会让路由在互通时直接翻车。

解决思路：

• 检查子网网段是否与其他已连接网络重叠
• GCP充值折扣 如果有 VPN/Interconnect，核对对端网段规划
• 必要时做路由与 NAT 策略重新梳理

坑 5：跨区域子网未覆盖，导致部分区域创建失败

共享 VPC 的子网与区域绑定。如果你只创建了某个区域的子网，却在另一区域启动实例，会出现你选不到子网或实例无法获取预期网络的情况。

解决思路：确保在需要的区域都完成对应子网创建，并在 Host 侧共享给 Service。

排查方法：当你遇到问题，不要靠祈祷，靠证据

当连通性或授权出现问题时，可以按“由粗到细”的方式排查：

1. 先确认共享是否真正生效

• 在 Service 项目创建资源时看是否能选择到 Host 的共享 VPC/子网
• 在 Host 的共享 VPC 页面查看 Service 项目是否已被授权

2. 再确认 IAM 是否允许

• 检查你用于部署/管理的身份（用户/服务账号）的角色绑定情况
• 确认角色的作用域（项目级/组织级）

3. 最后才看网络策略

• 检查实例的网络标签/服务账号是否匹配防火墙规则
• 检查路由（尤其自定义路由、是否存在到目标网段的路径）

最佳实践：把共享 VPC 做成可治理、可审计、可扩展的体系

共享 VPC 很适合多团队协作，但前提是你们要制定“怎么玩”的规则。下面是一些通常能减少争吵和返工的建议。

1. 网络资源尽量集中管理（Host 侧）

VPC、子网、关键路由、防火墙“骨架”建议由 Host 团队负责。Service 团队只在自己的责任边界内管理应用侧规则。

2. 统一命名与环境隔离

比如用 prod/dev/test 分离，或用不同 VPC/子网段隔离环境。即使你在共享，也要让边界清晰。

3. 使用标签或服务账号做防火墙匹配

防火墙规则建议基于一致的标识体系（例如 target tags 或 target service accounts），避免“靠猜”。

4. 记录 IP 段规划与用途

写在文档里很俗，但是真的救命。尤其当你换人、换团队、换运维时，文档是唯一不会忘的“记忆体”。

5. 审计与变更管理

共享 VPC 的改动影响面更大。建议为 Host 侧网络资源的变更建立流程，比如变更单、审批、回滚预案。

运维视角：共享 VPC 长期会遇到什么

很多人把共享 VPC 当成“上线一次就完事”。现实是：你会不断添加 Service 项目、扩容子网、调整路由、防火墙策略迁移，还可能引入新区域或新产品（例如 GKE）。

因此，运维上你需要关注：

• 子网扩容策略：IP 用完怎么办？提前准备预留或二次规划。
• 规则版本治理：防火墙/路由改动如何追踪、如何回滚。
• 计费与成本归属：Host 侧和 Service 侧的成本可能需要用标签或费用分摊策略管理。

如果你不想每天在“谁改的谁背锅”里消耗人生，最好把治理体系从一开始就建起来。

GCP充值折扣 一个小案例（假设情景）：两套业务团队如何共用同一张网

假设你们公司有：

• Host 项目（主机项目）：维护公司级 VPC，例如 vpc-prod，包含 us-central1 的子网 prod-us-central1-subnet
• Service 项目 A：业务 A，创建 VM 运行服务
• Service 项目 B：业务 B，创建 GKE 集群

配置完成后：

• 业务 A 的 VM 在创建时选择共享子网
• 业务 B 的 GKE 节点池也选择共享子网
• Host 侧配置防火墙基线，例如允许从特定子网访问 80/443
• 业务各自只维护应用级策略（例如更细粒度的安全设置）

这样做的好处是：网络治理一致、排查问题更有方向、团队之间不至于各搞一套“各自为政”的网络，最终导致互通与安全策略难以统一。

FAQ：你可能还有的疑问

Q1：共享 VPC 能不能共享整个区域的网络能力？

共享 VPC 共享的是网络资源（例如 VPC、子网）。子网与区域有关，所以通常要在对应区域创建子网并完成共享。并不是“一个授权就自动包含所有区域”。

Q2：Host 侧和 Service 侧的防火墙规则应该怎么分工？

常见做法是 Host 提供基线（骨架），Service 提供补充（按业务需求）。如果你们组织成熟，也可以更细分，但前提是规则匹配策略（标签/服务账号）要清晰可控。

Q3：权限配置要怎么验证？

最直接的方法是用目标身份尝试在 Service 项目创建资源：如果能选择共享网络/子网并完成实例创建，基本说明关键权限通了。若失败，结合错误信息再检查 IAM 与共享配置。

结语：把共享 VPC 当成“平台能力”，而不是一次性操作

“GCP 谷歌云账号共享 VPC 设置”本质上是一个平台化能力：让多团队在受控的网络边界下协作。你只要记住三件事：

• Host 侧负责网络资源的所有权与共享授权
• Service 侧通过 IAM 获得使用权限，并在正确区域选择共享子网
• GCP充值折扣 连通性最终依赖防火墙与路由策略

如果你在过程中觉得“明明都配了怎么还是不通”，别慌，先按顺序排查：共享是否生效 → 权限是否到位 → 网络策略是否匹配。多数问题都能在这条链路上找到答案。

最后送你一句真心话（来自加班经验）：共享 VPC 不是让你更快，而是让你以后更省心。前期多想一步，后期少踩一次坑。希望这篇文章能帮你少一点“玄学配置”，多一点“可预期结果”。