Question

我有2个私有和公共GKE集群，并使用cloudproxy作为gke应用程序访问cloudsql实例的工具。

用于开发/测试的公共集群设置

同时使用私有IP和公共IP启用了Cloud SQL。 GKE应用程序正在使用cloudproxy，其IP类型（公用，专用）的默认选项如下 Cloud SQL没有任何授权的网络。

在这种情况下，我的应用程序能够连接CloudSQL并正常运行。据我了解，由于未配置任何授权网络，因此应该通过私有方式连接到cloudsql。

用于生产的专用集群设置

同时使用私有IP和公共IP启用了Cloud SQL。 GKE应用程序使用带IP默认类型（公共，私有）的选项的cloudproxy

部署文件中的cloudsql-proxy设置

  - name: cloudsql-proxy
    image: gcr.io/cloudsql-docker/gce-proxy:1.11
    command: ["/cloud_sql_proxy"]
    args: ["-instances=$(REAL_DB_HOST)=tcp:$(REAL_DB_PORT)","-credential_file=/secrets/cloudsql/credentials.json"]

案例1 Cloud SQL没有任何授权的网络。结果：应用程序无法与Cloud SQL连接

案例2 Cloud SQL将私有GKE NAT网关作为授权网络结果：应用程序无法与Cloud SQL连接

也许可以从应用程序中删除cloudproxy可以正常工作（我尚待测试），但是由于在生产部署期间需要在部署文件中进行更改，因此不鼓励在开发环境中使用代理。

我无法理解是什么导致了gke私有集群中的cloudproxy连接失败。我们不应该在私有集群中使用cloudproxy吗？

更新由于禁用了哪个云代理无法连接云SQL的原因，云SQL管理员API已禁用。我已经在答案部分更新了答案。

Answer 1

这里的问题似乎是“我们应该在私有集群中使用Cloud SQL代理吗？”答案是“取决于”。不需要连接，但是它可以提供更高的安全性，因为您可以限制对Cloud SQL服务器的不必要访问。

Cloud SQL代理不为您的应用程序提供连接-它仅提供身份验证。它必须能够通过现有路径进行连接，但是必须使用服务帐户的IAM角色来验证连接。这也意味着它不必来自列入白名单的网络，因为它已通过其他方式进行了身份验证。

如果您要使用代理通过专用IP连接（而不是默认为公用），请使用-ip_address_types=PRIVATE-这将告诉代理改为与实例的专用IP连接。（请注意，如果代理缺少网络路径（例如，不在VPC上），则该代理仍将无法连接。）

Answer 2

@kurtisvg提供了一个有帮助的答案。

但是，真正的问题是SQL Admin API并启用它解决了该问题。查看日志后，我在下面的条目中找到了。

错误403：未配置访问。之前尚未在项目XXXXXX中使用Cloud SQL Admin API或将其禁用。通过访问https://console.developers.google.com/apis/api/sqladmin.googleapis.com/overview启用它吗？

GKE私有集群和Cloud sql代理连接

2 个答案: