GKE 上的 CloudSQL 代理:服务与边车

CloudSQL Proxy on GKE : Service vs Sidecar

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

我知道它主要用作sidecar。我已经将它用作两者(在非生产环境中),但我一直不明白为什么 sidecar 比服务更可取。有没有人可以赐教一下?

云 SQL Auth 代理是连接到云 SQL 的推荐方式,即使在使用私有 IP 时也是如此。这是因为 Cloud SQL Auth 代理使用 IAM 提供强大的加密和身份验证,这有助于确保您的数据库安全。

当您使用 Cloud SQL Auth 代理连接时,Cloud SQL Auth 代理会使用边车容器模式添加到您的 pod。 Cloud SQL Auth 代理容器与您的应用程序位于同一 pod 中,这使应用程序能够使用本地主机连接到 Cloud SQL Auth 代理,从而提高安全性和性能。

由于 sidecar 是一个与应用程序容器运行在同一个 Pod 上的容器,因为它与主容器共享相同的卷和网络,所以它可以“帮助”或增强应用程序的运行方式。在 Kubernetes 中,pod 是一组具有共享存储和网络的一个或多个容器。 sidecar 是 pod 中的实用程序容器,与主应用程序容器松散耦合。

Sidecar 优点: 随着 pods 数量的增加,无限扩展。可以自动注入。已被 serviceMeshes 使用。

Sidecar 缺点: 有点难以采用,因为开发人员不能只部署他们的应用程序,而是在部署中部署整个堆栈。它消耗更多资源并且更难保护,因为每个 Pod 都必须部署日志聚合器以将日志推送到数据库或队列。

有关详细信息,请参阅 documentation

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

当您 运行 云 SQL 代理时,您实质上是在说“我是用户 X,我被授权连接到数据库”。当您 运行 它作为一项服务时,连接到该数据库的任何人都被授权为“用户 X”。

你可以看到这个 warning in the Cloud SQL proxy example running as a service in k8s, or watch this video on Connecting to Cloud SQL from Kubernetes 这也解释了原因。