mat*_*ati
9
google-cloud-platform
我正在测试各种 GCP 功能，但我遇到了标题中的问题。经过一些实验，我认为以下内容应该成立：
- 2 个对等 VPC 不能共享相同的子网范围，而 VPC 共享是共享相同的子网：如果我们希望实例通信并调整防火墙 (FW) 规则，这有什么实际区别吗？
- 共享 VPC 创建了一种层级关系，其中一端是网络和 FW 规则的管理者，因此可以决定所有服务项目的能力并可以撤销共享，这也意味着宿主部分必须有权访问服务项目才能让他们挑选和允许他们使用宿主项目 VPC。无论如何，如果想要对等项目，VPC 对等连接需要对项目进行一定级别的访问，但是这 2 个项目是同等的（两端都必须允许对等连接）：这是管理/身份验证差异
- 共享 VPC 允许简化 FW 设置，因为您只有一个中心点来设置 FW 规则：您共享相同的一组子网；而对等互连 - 类似于 VPN - 需要在两端设置规则：这是一种管理简化
- 共享 VPC可以更快地耗尽其资源（IPv4 范围），但这意味着您连接了大量实例......
- VPC 对等互连可以进行最多 1 个级别的传递（菊花链）：我有 1 个从 VPC A 到 VPC B 的连接，一个从 VPC B 到 VPC C。VPC A 和 C无法通信，但 VPC B 可以与两者通信。相反，在共享场景中，项目只能同时是主机或服务，但我可以创建一个场景，其中多个项目共享同一子网并相互通信……这可能是最相关的我见过的不同
假设我们有N 个不同的项目，有N 个不同的管理员，如果所有部分都同意在实例之间建立某种网络连接，那么选择对等连接而不是共享还有其他优点/缺点吗？！
编辑
- 也许这才是真正最大的区别：如果一个服务项目使用了一个共享的 VPC，而你以后想删除它，你需要先创建一个新的 VPC（或使用服务项目的默认值），然后为所有实例重新分配一个新的 nic当前正在使用共享 VPC，让这个新 nic 使用项目自己的 VPC，重做 FW 规则并在将它们从共享 VPC 分离之前检查所有实例的正确连接。
- 此外，可以在同一项目中使用 VPC 对等，以增加工作负载之间的隔离，但让少数选定的 VM 进行通信。
编辑 2
- 截至目前 (2021-01) 共享 VPC 可以在第二个 NIC 上使用，但它是一个测试版功能
- 此外，一个网络不能添加超过 25 个对等互连，因此在所谓的中心辐射设计中让项目通过共享 VPC 进行通信是很常见的。
- 刚刚发现甚至可以在不同组织之间应用 VPC 对等互连！
谢谢