GKE 上的 CloudSQL 代理：服务与 Sidecar

Question

有谁知道在 Kubernetes 集群上安装 CloudSQL-Proxy（它允许我们安全地连接到 CloudSQL）作为服务而不是将其作为应用程序容器的 sidecar 的优点和缺点？

据我所知，它主要用作边车。我已经将它用作两者（在非生产环境中），但我一直不明白为什么 sidecar 比 service 更可取。有人可以启发我吗？

Answer 1

Sidecar 模式是首选，因为它是最简单且更安全的选择。Cloud SQL Auth 代理的流量未加密或经过身份验证，并且依赖于用户限制对代理的访问（通常是运行本地主机）。

当您运行 Cloud SQL 代理时，您实际上是在说“我是用户 X，并且我有权连接到数据库”。当您将其作为服务运行时，连接到该数据库的任何人都将以“用户 X”的身份进行连接授权。

您可以在 k8s 中作为服务运行的 Cloud SQL 代理示例中看到此警告，或者观看有关从 Kubernetes 连接到 Cloud SQL 的视频，其中也解释了原因。

Answer 2

即使使用私有 IP，建议使用 Cloud SQL Auth 代理连接到 Cloud SQL。这是因为 Cloud SQL Auth 代理使用 IAM 提供强大的加密和身份验证，这有助于确保数据库的安全。

\n

当您使用 Cloud SQL Auth 代理进行连接时，Cloud SQL Auth 代理将使用 sidecar 容器模式添加到您的 Pod。Cloud SQL Auth 代理容器与您的应用程序位于同一 Pod 中，这使得应用程序能够使用 localhost 连接到 Cloud SQL Auth 代理，从而提高安全性和性能。

\n

由于 sidecar 是与应用程序容器运行在同一个 Pod 上的容器，由于它与主容器共享相同的卷和网络，因此它可以 \xe2\x80\x9chelp\xe2\x80\x9d 或增强应用程序的运行方式。在 Kubernetes 中，Pod是一组具有共享存储和网络的一个或多个容器。sidecar 是 pod 中的实用程序容器，\xe2\x80\x99 与主应用程序容器松散耦合。

\n

Sidecar 的优点：随着 pod 数量的增加，可以无限扩展。可以自动注射。已被 serviceMeshes 使用。

\n

Sidecar 缺点：采用起来有点困难，因为开发人员不仅可以部署他们的应用程序，还可以在部署中部署整个堆栈。它消耗更多的资源，并且更难保证安全，因为每个 Pod 都必须部署日志聚合器来将日志推送到数据库或队列。

\n

请参阅文档以获取更多信息。

\n