在GKE上使用CloudSQL代理：Service与Sidecar区别

Question

有人知道在Kubernetes集群中将CloudSQL-Proxy（允许我们安全连接到CloudSQL）安装为服务与将其作为应用程序容器的旁车相比的利弊吗？

我知道它通常被用作旁车。 我在非生产环境中都使用过这两种方式，但我从来没有明白旁车比服务更可取的原因。 有人可以对我解释一下吗？

- Sayon Roy Choudhury

Answer 1

边车模式是首选的，因为它是最简单和更安全的选择。流量传输到Cloud SQL身份验证代理不加密或身份验证，并依赖用户限制对代理的访问（通常是通过运行本地主机来实现）。

当您运行Cloud SQL代理时，您基本上在说“我是用户X，我被授权连接到数据库”。当您将其作为服务运行时，连接到该数据库的任何人都被连接授权为“用户X”。

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

- kurtisvg

Answer 2

Cloud SQL认证代理是连接到Cloud SQL的推荐方式，即使使用私有IP也是如此。这是因为Cloud SQL认证代理提供了强大的加密和基于IAM的身份验证，可以帮助保护您的数据库安全。

当您使用Cloud SQL认证代理进行连接时，Cloud SQL认证代理将使用sidecar容器模式添加到您的Pod中。Cloud SQL认证代理容器与您的应用程序在同一个Pod中，这使得应用程序可以使用本地主机连接到Cloud SQL认证代理，从而提高了安全性和性能。

由于sidecar是在同一个Pod上运行的容器，它与主应用程序容器共享相同的卷和网络，因此它可以“帮助”或增强应用程序的操作。在Kubernetes中，pod是具有共享存储和网络的一个或多个容器的组。Sidecar是Pod中与主应用程序容器松散耦合的实用程序容器。 Sidecar优点：随着Pod数量的增加而无限扩展。可以自动注入。已被serviceMeshes使用。 Sidecar Cons: 有一点难以采用，因为开发人员不能只部署他们的应用程序，而是必须在部署中部署整个堆栈。它消耗更多资源，并且更难以保护，因为每个Pod必须部署日志聚合器将日志推送到数据库或队列中。

更多信息请参阅文档。

- Jyothi Kiranmayi