Pgbouncer：如何在 Kubernetes 集群中正确运行

Question

背景：我目前使用 pgbouncer sidecar 容器运行一些 kubernetes pod。我一直在使用带有变通方法的 sidecar（将在 k8s 1.18 中解决）遇到烦人的行为，但之前提出了一个关于在 k8s 中运行 pgbouncer 的问题。

很多人推荐 pgbouncer 的 sidecar 方法，但我想知道为什么每次运行一个 pgbouncer 说：k8s 集群中的机器不会更好？我承认我对 pgbouncer 或 k8s 网络的理解不够深入，无法理解这两种方法的含义。

---

编辑：

添加上下文，因为我的问题似乎不够清楚。

我正在尝试在 kubernetes 集群中运行 pgbouncer 的两种方法之间做出决定。 PostgreSQL 服务器未在此集群中运行。这两种方法是：

1. 在我的所有 pod 中将 pgbouncer 作为 sidecar 容器运行。我有许多 pod：网络服务器部署上的一些副本、异步作业部署和几个 cron 作业。
2. 将 pgbouncer 作为单独的部署运行。我计划在 k8s 集群上的每个节点上运行 1 个 pgbouncer 实例。

我担心 (1) 不能很好地扩展。如果我的 PostgreSQL 主服务器最多有 100 个连接，并且每个池最多有 20 个连接，我可能会冒着很早就饱和连接的风险。此外，由于新的 pgbouncer sidecars 与被删除的旧图像一起存在，我冒着在推送期间使 master 上的连接饱和的风险。

然而，我几乎从未见过 (2) 推荐。似乎每个人都推荐（1），但缺点对我来说似乎很明显。通过连接到我的 pod 外部的 pgbouncer 所产生的网络惩罚是否足够大以引起注意？ pgbouncer 是否足够聪明，可以处理许多其他可能使连接饱和的 pgbouncer 实例？

Answer 1

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

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

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