Pgbouncer: как правильно работать в кластере kubernetes

Question

Предыстория: в настоящее время я запускаю несколько модулей kubernetes с контейнером коляски pgbouncer. Я столкнулся с раздражающим поведением с колясками (которые будут рассмотрены в k8s 1.18), которые имеют обходные пути, но подняли более ранний вопрос о запуске pgbouncer внутри k8s.

Многие люди рекомендуют подход с коляской для pgbouncer , но мне интересно, почему запуск одного pgbouncer на каждый: машина в кластере k8s не будет лучше? Я признаю, что мне не хватает глубокого понимания сетей pgbouncer или k8s, чтобы понять последствия любого подхода.

---

РЕДАКТИРОВАТЬ:

Добавление контекст, как кажется, мой вопрос не был достаточно ясен.

Я пытаюсь выбрать между двумя подходами запуска pgbouncer в кластере kubernetes. Сервер PostgreSQL не работает в этом кластере. Два подхода:

1. Запуск pgbouncer в качестве контейнера с коляской во всех моих модулях. У меня есть несколько модулей: несколько реплик при развертывании веб-сервера, развертывание заданий asyn c и пара заданий cron.
2. Запуск pgbouncer в качестве отдельного развертывания. Я планирую запустить 1 экземпляр pgbouncer на узел в кластере k8s.

Я беспокоюсь, что (1) не будет хорошо масштабироваться. Если у моего PostgreSQL master максимум 100 соединений, а в каждом пуле максимум 20 соединений, я потенциально рискую насытить соединения довольно рано. Кроме того, я рискую насытить соединения на ведущем устройстве во время проталкивания, так как наряду с удаляемым старым образом существуют новые коляски pgbouncer.

Я, однако, почти никогда не вижу рекомендуемых (2). Кажется, что все рекомендуют (1), но недостатки кажутся мне вполне очевидными. Является ли сетевой штраф, который я понесу, подключившись к pgbouncer за пределами моего модуля, будет достаточно большим, чтобы заметить? Является ли pgbouncer достаточно умным, чтобы справляться со многими другими экземплярами pgbouncer, которые могут насытить соединения?

Answer 1

Мы запускаем pgbouncer в производство в Kubernetes. Я ожидаю, что лучший способ сделать это зависит от варианта использования. Мы не используем подход с коляской, но вместо этого запускаем pgbouncer как отдельное «развертывание», и приложение получает к нему доступ через «сервис». Это связано с тем, что для нашего варианта использования у нас есть 1 postgres экземпляр (т. Е. Одна физическая машина БД) и множество копий одного и того же приложения, которые обращаются к одному и тому же экземпляру (но используют разные базы данных в этом экземпляре). Pgbouncer используется для управления активным ресурсом соединений. Мы объединяем соединения независимо для каждого приложения, потому что природа нашего приложения состоит в том, чтобы иметь много одновременных соединений и не слишком много транзакций. В настоящее время мы работаем с 1 модулем (без реплик), потому что это приемлемо для нашего варианта использования, если pgbouncer перезапускается быстро. Многие приложения запускают свои собственные pgbouncers, и у каждого приложения есть несколько компонентов, которым требуется доступ к БД (поэтому каждый pgbouncer объединяет соединения одного экземпляра приложения). Это делается так: https://github.com/astronomer/airflow-chart/tree/master/templates/pgbouncer

Выше не указано, как настроить учетные данные для доступа к базе данных. Вышеупомянутый связанный шаблон ожидает, что секрет уже существует. Я ожидаю, что вам нужно будет адаптировать шаблон к вашему варианту использования, но это должно помочь вам понять идею.

У нас были некоторые производственные проблемы. Прежде всего нам нужно больше исследовать, как заменить или переместить pgbouncer, не прерывая существующие соединения. Мы обнаружили, что соединение приложения с pgbouncer отслеживает состояние (конечно, потому что оно объединяет транзакции), поэтому, если контейнер pgbouncer (pod) заменяется на новый сервис, тогда существующие соединения отбрасываются с точки зрения приложения. Это будет хорошо, даже если вы запускаете реплики pgbouncer, если у вас есть приложение, в котором вы можете гарантировать, что редко сбрасываемые соединения будут повторяться и использовать липкие сеансы Kubernetes в «сервисе». Наша организация по-прежнему нуждается в дополнительном расследовании, чтобы оно работало идеально.