私网连接：PSA、PSC 与服务访问

验证：未记录

适用版本: 未记录
验证范围: 尚未登记验证记录。

按连接对象选择机制，先确认源/目标 VPC、Region 和地址范围。

常用操作#

替换为实际资源；本段不依赖 lab.env。

PROJECT_ID='REPLACE_PROJECT_ID'
NETWORK='REPLACE_NETWORK'

gcloud compute networks peerings list --project="$PROJECT_ID" --network="$NETWORK"
gcloud compute addresses list --project="$PROJECT_ID" --global \
  --filter='purpose=VPC_PEERING'

容易踩的坑#

Auth Proxy 不建立 VPN，PSC endpoint 也不让两个 VPC 全网互通。 前者仍需可达 SQL 的网络路径；后者只连接发布的服务，不能当作传递路由。

Cloud Run all-traffic egress 会使普通互联网出口依赖 VPC 路由/NAT。

配置说明与完整示例（按需展开）

先分清连接方式#

需求	常见机制	不要混淆
同一组织的多个项目共享网络	Shared VPC：host/service project	IAM 与网络资源归属分别管理
两个 VPC 互通	VPC Network Peering	不支持传递路由；地址不能重叠
访问 Google 托管服务的私有地址	Private Services Access（PSA）	预留地址段 + Service Networking peering，本篇使用它
多个独立 VPC 分别访问同一 Cloud SQL PSC 实例	Private Service Connect（PSC）	实例启用 PSC、允许 consumer projects，各 VPC 配置 endpoint 与 DNS；不套用下方 PSA peering 命令
无外部 IP 的 VM 访问 Google API	Private Google Access	不代替普通互联网 NAT
机房/其他云接入	HA VPN 或 Interconnect + Cloud Router	要另外设计 BGP、冗余、CIDR 和 DNS
Cloud Run 访问 VPC	Direct VPC egress 或 Connector	配置出站不等于自动开放入站

AWS 的 VPC Peering、PrivateLink、 Shared VPC 与 GCP 这些机制只有部分对应关系。Private Services Access

两个 VPC 的 Peering 配置、跨 Region 访问与路由排障见 VPC 通信与路由。

订单 Worker 改走私有 SQL#

前置：综合项目成功；VPC 实验的 lab-vpc/lab-subnet 位于同一项目/区域。需要网络、Service Networking、SQL、Cloud Run 管理权限。只操作本次实验的 orders-pg。

source lab.env
gcloud services enable servicenetworking.googleapis.com compute.googleapis.com
# 自动选择不重叠的预留范围；已有 PSA 的项目先检查现有连接，不重复创建。
gcloud compute addresses create lab-google-services --global --purpose=VPC_PEERING --prefix-length=16 --network=lab-vpc
gcloud services vpc-peerings connect --service=servicenetworking.googleapis.com --ranges=lab-google-services --network=lab-vpc
gcloud sql instances patch orders-pg --network="projects/$PROJECT_ID/global/networks/lab-vpc"
export PRIVATE_SQL_IP=$(gcloud sql instances describe orders-pg --format=json | jq -r '.ipAddresses[] | select(.type=="PRIVATE") | .ipAddress')
gcloud sql instances patch orders-pg --ssl-mode=ENCRYPTED_ONLY

本次先保留公共 IP，避免应用尚未改好就断开旧连接。Cloud SQL 私有 IP

综合项目的新代码支持 DB_SSLMODE。若你之前构建的是旧镜像，先按项目篇重新构建并部署包含该参数的镜像，再执行：

gcloud run services update orders-worker --region="$REGION" --network=lab-vpc --subnet=lab-subnet --vpc-egress=private-ranges-only --clear-cloudsql-instances --update-env-vars="DB_HOST=$PRIVATE_SQL_IP,DB_SSLMODE=require"

这条路径是 Worker → Direct VPC egress → 私有 IP:5432 → PostgreSQL TLS，不用内置 Auth Proxy；数据库密码来自原 Secret。Cloud SQL Client 角色不代替 TCP 路径中的数据库认证。

sslmode=require 提供传输加密，但不是完整的服务端证书/主机名验证；这里用于隔离沙箱。生产应配置验证服务端身份的 TLS，或使用支持 private IP 的 Cloud SQL Connector/Proxy。Direct VPC

验收、关闭公网与回滚#

重新提交新 UUID 订单，确认 SQL 落库、归档完成。
检查 worker revision 的 VPC 设置、DB_HOST 和日志，确认不再依赖 /cloudsql socket。
再关闭公共地址并重复端到端验收：

gcloud sql instances patch orders-pg --no-assign-ip
gcloud sql instances describe orders-pg --format='yaml(ipAddresses)'

若失败，按顺序查地域/ subnet、IP 容量、路由/防火墙、TLS、数据库用户权限。设置 all-traffic 会让普通互联网出口也依赖 VPC/NAT，本篇不用它。

实验回滚：

gcloud sql instances patch orders-pg --assign-ip
export CONNECTION_NAME=$(gcloud sql instances describe orders-pg --format='value(connectionName)')
gcloud run services update orders-worker --region="$REGION" --clear-network --add-cloudsql-instances="$CONNECTION_NAME" --update-env-vars="DB_HOST=/cloudsql/$CONNECTION_NAME" --remove-env-vars=DB_SSLMODE

私有 IP 配置不能简单当成一个可随意拔掉的网卡。若最终删项目，先删除依赖的 SQL 实例，再删除 PSA：

gcloud services vpc-peerings delete --service=servicenetworking.googleapis.com --network=lab-vpc
gcloud compute addresses delete lab-google-services --global

服务释放连接可能有延迟；若提示仍有生产者资源，不强制拆共享连接，先核对剩余实例和服务，再清理 VPC。