postgresql - Pgbouncer:如何在 kubernetes 集群中正确运行

Question

背景:我目前使用 pgbouncer sidecar 容器运行一些 kubernetes pod。我一直在遇到带有变通方法的 sidecar(将在 k8s 1.18 中解决)的烦人行为，但提出了一个关于在 k8s 中运行 pgbouncer 的早期问题。
许多人推荐 pgbouncer 的 sidecar 方法，但我想知道为什么每次运行一个 pgbouncer 说:k8s 集群中的机器不会更好？我承认我对 pgbouncer 或 k8s 网络没有足够的深入理解来理解这两种方法的含义。

编辑:
添加上下文，因为我的问题似乎不够清楚。
我试图在 kubernetes 集群中运行 pgbouncer 的两种方法之间做出决定。 PostgreSQL 服务器未在此集群中运行。这两种方法是:

在我的所有 pod 中将 pgbouncer 作为 sidecar 容器运行。我有许多 pod:网络服务器部署上的一些副本、异步作业部署和几个 cron 作业。

将 pgbouncer 作为单独的部署运行。我计划在 k8s 集群上为每个节点运行 1 个 pgbouncer 实例。

我担心 (1) 不能很好地扩展。如果我的 PostgreSQL 主节点最多有 100 个连接，并且每个池最多有 20 个连接，我可能会冒着很早就饱和连接的风险。此外，由于新的 pgbouncer sidecar 与被删除的旧图像一起存在，因此我可能会在推送期间冒着使 master 上的连接饱和的风险。
但是，我几乎从未看到推荐的 (2)。似乎每个人都推荐(1)，但缺点对我来说似乎很明显。连接到 pod 外的 pgbouncer 所产生的网络损失是否大到足以引起注意？ pgbouncer 是否足够聪明来处理许多其他可能使连接饱和的 pgbouncer 实例？

Answer 1

我们在 Kubernetes 的生产环境中运行 pgbouncer。我希望最好的方法是依赖于用例。我们不采用 sidecar 方法，而是将 pgbouncer 作为单独的“部署”运行，应用程序通过“服务”访问它。这是因为对于我们的用例，我们有 1 个 postgres 实例(即一台物理 DB 机器)和同一应用程序的许多副本访问同一实例(但在该实例中使用不同的数据库)。 Pgbouncer 用于管理事件连接资源。我们为每个应用程序独立地汇集连接，因为我们的应用程序的性质是有许多并发连接而不是太多事务。我们目前正在运行 1 个 pod(没有副本)，因为如果 pgbouncer 快速重启，这对于我们的用例来说是可以接受的。许多应用程序都运行自己的 pgbouncer，并且每个应用程序都有多个需要访问数据库的组件(因此每个 pgbouncer 都在汇集一个应用程序实例的连接)。是这样做的https://github.com/astronomer/airflow-chart/tree/master/templates/pgbouncer

以上不包括为访问数据库设置正确的凭据。上面的链接模板期望一个 secret 已经存在。我希望您需要根据您的用例调整模板，但它应该可以帮助您理解这个想法。

我们有一些生产方面的担忧。主要是我们仍然需要对如何在不中断现有连接的情况下替换或移动 pgbouncer 进行更多调查。我们发现应用程序与 pgbouncer 的连接是有状态的(当然是因为它正在汇集事务)，所以如果 pgbouncer 容器(pod)在服务后面换出一个新的容器，那么从应用程序的角度来看，现有的连接将被删除。如果您有一个应用程序可以确保很少断开的连接重试并在“服务”上使用 Kubernetes 粘性 session ，那么即使运行 pgbouncer 副本也应该没问题。我们的组织仍需要进行更多调查才能使其完美运行。