背景:我目前使用 pgbouncer sidecar 容器运行一些 kubernetes pod。我一直在使用带有变通方法的 sidecar(将在 k8s 1.18 中解决)遇到烦人的行为，但在 k8s 中运行 pgbouncer 之前提出了一个问题。
许多人推荐 pgbouncer 的 sidecar 方法，但我想知道为什么每次运行一个 pgbouncer 说:k8s 集群中的机器不会更好？我承认我对 pgbouncer 或 k8s 网络没有足够的深入理解来理解这两种方法的含义。
编辑:
添加上下文，因为我的问题似乎不够清楚。
我试图在 kubernetes 集群中运行 pgbouncer 的两种方法之间做出决定。 PostgreSQL 服务器未在此集群中运行。这两种方法是:
我担心 (1) 不能很好地扩展。如果我的 PostgreSQL 主节点最多有 100 个连接，而每个池最多有 20 个连接，我可能会冒着很早就饱和连接的风险。此外，由于新的 pgbouncer sidecar 与被删除的旧图像一起存在，因此我可能会在推送期间使 master 上的连接饱和。
但是，我几乎从未看到推荐的 (2)。似乎每个人都推荐(1)，但缺点对我来说似乎很明显。连接到 pod 外的 pgbouncer 所产生的网络损失是否大到足以引起注意？ pgbouncer 是否足够聪明来处理许多其他可能使连接饱和的 pgbouncer 实例？
最佳答案
我们在 Kubernetes 的生产环境中运行 pgbouncer。我希望最好的方法是依赖于用例。我们不采用 sidecar 方法，而是将 pgbouncer 作为单独的“部署”运行，应用程序通过“服务”访问它。这是因为对于我们的用例，我们有 1 个 postgres 实例(即一台物理数据库机器)和同一应用程序的许多副本访问同一实例(但在该实例中使用不同的数据库)。 Pgbouncer 用于管理事件连接资源。我们为每个应用程序独立地汇集连接，因为我们的应用程序的性质是有许多并发连接而不是太多事务。我们目前正在运行 1 个 pod(没有副本)，因为如果 pgbouncer 快速重启，这对于我们的用例来说是可以接受的。许多应用程序都运行自己的 pgbouncer，并且每个应用程序都有多个需要访问数据库的组件(因此每个 pgbouncer 都在汇集一个应用程序实例的连接)。是这样完成的 https://github.com/astronomer/airflow-chart/tree/master/templates/pgbouncer
以上不包括为访问数据库设置正确的凭据。上面的链接模板期望一个 secret 已经存在。我希望您需要根据您的用例调整模板，但它应该可以帮助您理解这个想法。
我们有一些生产方面的担忧。主要是我们仍然需要对如何在不中断现有连接的情况下替换或移动 pgbouncer 进行更多调查。我们发现应用程序与 pgbouncer 的连接是有状态的(当然是因为它正在汇集事务)，因此如果 pgbouncer 容器(pod)在服务后面换出一个新的容器，那么从应用程序的角度来看，现有连接将被删除。如果您有一个应用程序可以确保很少断开的连接重试并在“服务”上使用 Kubernetes 粘性 session ，那么即使运行 pgbouncer 副本也应该没问题。我们的组织仍需要进行更多调查才能使其完美运行。
关于postgresql - Pgbouncer:如何在 kubernetes 集群中正确运行，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/60132131/