基于其github 页面,建议将其设置为 sidecar 容器,而不是集群服务。我的问题是,如果我有很多将 cloud sql proxy 作为 sidecar 容器的 pod,是否会出现任何问题(例如性能、连接数)?创建服务似乎是合理的。
如果我遗漏了任何内容请告诉我。
答案1
将此答案发布为社区维基作为该问题的答案可能会引起主观臆断。
基于其github 页面,建议将其设置为 sidecar 容器,而不是集群服务。
不仅您提到的网站,还有以下官方文档CloudSQL
:
要从在 Google Kubernetes Engine 中运行的应用程序访问 Cloud SQL 实例,您可以使用 Cloud SQL 代理(具有公共或私有 IP),也可以使用私有 IP 地址直接连接。
Cloud SQL Proxy 是连接 Cloud SQL 的推荐方式,即使使用私有 IP 也是如此。这是因为代理使用 IAM 提供强大的加密和身份验证,这有助于确保数据库的安全。
创建一个服务似乎是合理的。
您可以了解为什么建议使用代理而不是生成服务:
出于以下几个原因,我们建议将其作为单独的服务运行:
- 防止您的 SQL 流量在本地暴露;代理对传出连接提供加密,但您需要限制传入连接的暴露
- 防止单点故障;每个应用程序对数据库的访问都是独立的,从而使其更具弹性。
- 限制对代理的访问,允许您使用每个应用程序的 IAM 权限,而不是将数据库暴露给整个集群
- 允许您更准确地确定资源请求的范围;由于代理对资源的消耗与使用呈线性关系,因此此模式允许您更准确地确定范围并请求资源以匹配您的应用程序的扩展
Cloud.google.com:SQL:文档:MySQL:连接 Kubernetes Engine:将 CloudSQL 代理作为 sidecar 运行
至于活动连接数(根据使用的解决方案而不同):
- Cloud.google.com:SQL:文档:MySQL:配额
- Cloud.google.com:SQL:文档:PostgreSQL:配额
- Cloud.google.com:SQL:文档:SQL Server:配额
另外,添加(有效管理与数据库的连接)可能会有益:
其他资源: