背景：我目前使用pgbouncer sidecar容器运行了一些kubernetes pod。我遇到了一些使用sidecar的恼人行为（将在k8s 1.18中解决），这些行为有解决方案，但我之前提出了一个关于在k8s中运行pgbouncer的问题。
很多人推荐pgbouncer的sidecar方法，但我想知道为什么在k8s集群中运行一台pgbouncer不会更好？我承认我对pgbouncer或k8s网络没有足够深入的理解来理解这两种方法的含义。
编辑：
添加上下文，因为似乎我的问题不够清楚。
我正在尝试在kubernetes集群中选择两种运行pgbouncer的方法。PostgreSQL服务器不在这个集群中运行。这两种方法是：
1.在我所有的pod中运行pgbouncer作为sidecar容器。我有很多pod：在web服务器部署上的一些副本，一个cronc作业部署，和几个cron作业。
1.将pgbouncer作为一个单独的部署运行。我计划在k8s集群上每个节点运行1个pgbouncer示例。
我担心（1）不能很好地扩展。如果我的PostgreSQL master最多有100个连接，每个池最多有20个连接，我可能会冒着连接饱和的风险。此外，在推送期间，我会冒着master上连接饱和的风险，因为新的pgbouncer sidecar与旧的镜像一起被删除。
然而，我几乎从来没有看到（2）推荐。似乎每个人都推荐（1），但缺点对我来说似乎很明显。连接到pgbouncer外部的pgbouncer会带来足够大的网络损失吗？pgbouncer是否足够聪明，可以处理可能使连接饱和的许多其他pgbouncer示例？
1条答案
按热度按时间jslywgbw1#
我们在Kubernetes上的生产环境中运行pgbouncer。我希望最好的方法是依赖于用例。我们不采用sidecar方法，而是将pgbouncer作为一个单独的“部署”运行，应用程序通过“服务”访问它。这是因为对于我们的用例，我们有1个postgres示例（即一台物理数据库机器）和访问同一示例的同一应用程序的多个副本（但在该示例中使用不同的数据库）. Pgbouncer用于管理活动连接资源。我们为每个应用程序独立地池化连接，因为我们的应用程序的本质是有许多并发连接，而不是太多的事务。我们目前运行1个pod（没有副本），因为如果pgbouncer快速重启，这对于我们的用例是可以接受的。许多应用程序都运行自己的pgbouncer，每个应用程序都有多个组件需要访问DB（因此每个pgbouncer都是应用程序的一个示例的池连接）。它是这样完成的https://github.com/apache/airflow/tree/main/chart/templates/pgbouncer
上面的内容不包括获取访问数据库的凭据设置。上面的链接模板预计已经存在一个秘密。我希望您需要根据您的用例调整模板，但它应该可以帮助您了解这个想法。
我们有一些生产方面的问题。首先，我们仍然需要做更多的调查，如何在不中断现有连接的情况下替换或移动pgbouncer。我们发现应用程序与pgbouncer的连接是有状态的。（当然，因为它是池化事务），所以如果pgbouncer容器（pod）在服务后面被换为新的容器，然后从应用程序的Angular 删除现有连接。如果您有一个应用程序，可以确保很少删除的连接重试并利用“服务”上的Kubernetes粘性会话，则即使运行pgbouncer副本也应该可以我们的组织仍需要进行更多的调查，以使其完美地运作。