当尝试评估如何从Google Kubernetes Engine pod连接到Cloud SQL数据库时，有几种方法可以做到这一点。一种是使用挎斗云代理。另一种是使用私有 IP 并在两者之间使用 SSL 连接。两者都有明确的理由吗？还是它们都具有相同的功能？有没有一个被认为是"最佳实践"？
云 SQL 代理挎斗
云 sql 代理挎斗与托管在 Google 基础架构上的代理服务建立 TCP 连接。然后，这会将您连接到 Google 网络上的云 SQL 实例。
优点
- 建立安全连接，而无需管理应用程序中的加密材料
- 连接到实例，您无需管理 DNS 记录或 IP 地址
缺点
- 您必须创建存储服务帐户密钥的机密。
- 您必须在 Pod 旁边管理一个 sidecar 实例，如果该实例失败，您将无法再连接到您的数据库
- 由于代理层的层数而增加的延迟
私有 IP + SSL
使用私有 IP 并将实例连接到您的 VPC 允许您使用内部 IP 地址(未公开路由(，并将流量保留在您的 VPC 实例中。最重要的是，设置与数据库的仅SSL连接，以确保流量在点对点之间是安全的。
优点
- 与数据库的低延迟连接，因为它是点对点连接
- 管理服务之间的密钥
- 无需外部依赖项或系统即可在两者之间连接
缺点
- 您必须在连接内管理 SSL 证书
- 您必须验证群集中的 IP 和 DNS 记录设置是否正确
我错过了什么吗？这两者确实提供了同样的东西吗？两者之间没有绝对明确的赢家，你可以选择你认为最适合你的风格的一个吗？
最佳做法是使用代理。从安全的角度来看，它们都是不错的选择，但我发现管理自己的SSL密钥的混乱只是我不需要的麻烦。此外，正如John在他的评论中提到的，如果你出于任何原因转移区域或更改IP，你必须改变容器内容，而不仅仅是代理启动上的标志。当然，您可以使用容器上的环境变量来缓解这种情况，但这是另一回事。
代理 IMO 上有一个轻微的安全边缘，因为如果您的密钥被泄露，代理连接生成的临时密钥的寿命比您自己生成的 SSL 密钥短(除非您在 API 中使用临时密钥调用(。因此，如果您的应用程序中发现漏洞，并且密钥遭到入侵，则有一个较小的窗口，任何人都可以对您的数据库执行恶意操作。但是，特别是如果您只使用一个不太重要的 VPC，但仍然大于零。