我正在创建一个谷歌云设置，其中包含多个区域中的多个实例组 (3(。它们都位于同一个 VPC 中。
地区：
- 美国中部1
- 欧洲-北部1
- 亚洲东部1
所有三个实例组都有 2 个虚拟机。它是一个HTTP(S(负载均衡器，当我访问负载均衡器的公共IP地址时，我看到apache欢迎页面(apache安装在虚拟机上(。所以这行得通。
我还有一个Cloud SQL(PostgreSQL(数据库。我想通过它的私有 IP 访问此数据库。我已将虚拟机使用的 VPC 网络与云 SQL 实例的私有 IP 相关联。此实例在 us-central1 区域中运行。
现在，问题是：它不起作用。 :)我在文档中做了一些研究，我发现：
您必须选择要使用的 VPC 网络。您将用于连接到 Cloud SQL 实例(计算引擎实例 [VM] 或 Google Kubernetes Engine 实例(的 Google Cloud 资源必须使用此 VPC 网络才能连接。这些资源还必须与云 SQL 实例位于同一区域。
来源： https://cloud.google.com/sql/docs/postgres/configure-private-ip
为了进行测试，我在 us-central1 区域(未与实例组关联(中添加了一个新的虚拟机，并使用正确的 VPC。当我在此虚拟机上安装 postgresql 客户端时，我可以连接到数据库。但是，当我在欧洲北部 1 区域(也未与实例组关联(并使用正确的 VPC 创建另一个虚拟机时，我无法连接到数据库。因此，文档(令人惊讶(是正确的：与运行云 SQL 实例的区域位于不同区域的实例无法通过私有 IP 连接到云 SQL。
我现在的问题是：解决此问题的最佳方法是什么，以便不同实例组中的所有虚拟机都可以连接到同一个数据库。我是否应该在不同的区域中创建多个 Cloud SQL 实例，并在插入/更新/删除某些数据时复制每个数据库？对我来说，这似乎是很多不必要的流量和负载。
另一种选择是(我认为(是使用Cloud Spanner。我刚刚发现了这个选项，我目前正在阅读文档。这是要走的路吗？
编辑：Cloud Spanner似乎很有前途，但我看到它也非常昂贵。 1 个具有 GB 存储空间的节点约为 650 美元/月。
另一种选择是通过公共 IP 访问云 SQL 数据库。问题是：我应该将每个 VM IP 地址列入白名单，并且由于我使用自动缩放，因此 VM 是随时随地创建的(使用新的 IP 地址(。如何解决此问题，以便将新虚拟机自动列入数据库的白名单？
编辑：根据Gabe Weiss的回答，我创建了一个新的(测试(VM，并安装了云SQL代理和postgresql-client。它有效，当我建立连接或进行查询时，一切都很好。
现在，问题是：它在我的nodejs应用程序中不起作用。我正在使用节点发布 (https://node-postgres.com/(，我的连接配置是这样的：
const db = new Pool({
host: '127.0.0.1',
port: 5432,
user: 'postgres',
password: 'postgres',
database: 'postgres'
})
我还尝试将"127.0.0.1"替换为本地主机，我删除了端口，...什么都没用。凭据正确。
编辑 2：当我在后台运行cloud_sql_proxy，并且我也运行我的 nodejs 应用程序，并导航到 http：//external_ip_address：8000/node，我在控制台中看到一个日志：
2020/01/22 17:55:20 New connection for "project-id:region:instance-name"
但是 10 秒后，我得到这个：
2020/01/22 17:57:00 Client closed local connection on 127.0.0.1:5432
编辑3：
我还尝试将主机更改为/cloudsql/instance_connection_name，但也没有结果。
const db = new Pool({
host: '/cloudsql/[project-id]:[region]:[instance-name]',
port: 5432,
user: 'postgres',
password: 'postgres',
database: 'postgres'
})
Spanner绝对是一种选择，因为与跨区域连接到 Cloud SQL 相比，使用 Spanner 进行全局一致的设置可能会获得更好的延迟。
另一种选择是查看 VPC 对等：https://cloud.google.com/vpc/docs/vpc-peering 我认为你可以跨区域做到这一点，虽然我还没有玩过它，但这可能只是"工作"与私有 IP。
或者，如果您对应用程序中的一些延迟感到满意，则通过公共 IP 连接到 Cloud SQL 是一个不错的选择，但不要使用允许的网络(白名单(。要么尽可能使用代理，要么设置 SSL 连接(这有点痛苦，但绝对值得(。
我这里有一篇关于使用公共 IP + 云 SQL 代理的详细博客：https://medium.com/@GabeWeiss/connecting-cloud-sql-public-ip-sql-proxy-5513f59e5a9e，这是一种相对简单的从 VM 开始的方法。
解决方案
所以解决方案非常简单：它与某些配置无关，但与我的nodejs代码有关。我忘记了 postgresql 查询是一个承诺，所以我必须等待结果返回。添加异步/等待解决了这个问题。