Комментарии
Хочу сразу извиниться, что не дал ранее развёрнутый ответ. Дело в том, что Zalando даже в своей документации советует использовать свою сборку Spilo, в дефолте чего-то может не быть, версии могут быть не те. Именно поэтому в операторе возможно настроить все используемые образа. Соответственно вы можете использовать вместо pgbouncer odyssey, просто сделайте образ, который бы имел сходный интерфейс и настраивался через переменные окружения. Я тоже смотрел в эту сторону и даже начинал писать скрипт конфигурации, просто пока никто из клиентов такое не попросил.

Возможность кастомизации — это еще одна из причин, по которой нас и подкупил этот оператор
Да, уже напомнили про него. Пока выглядит заметно более сложным в использовании, аналогично Crunchy Data PostgreSQL Operator.

Обязательно попробуем его и дополним статью.

А есть сравнение производительности такого кластера в кубернетес с аналогичным на голой виртуалке?
Когда я игрался с zalando оператором у меня вышла разница чуть ли не в полтора раза по сравнению с дефолтным инстансом постгри. Вероятно я просто не смог нормально приготовить оператор...

У нас бы немного другая цель. А что вы понимаете под:
Когда я игрался с zalando оператором у меня вышла разница чуть ли не в полтора раза по сравнению с дефолтным инстансом постгри

Подразумевается производительность?

Я думаю, что тут два момента


  1. нельзя сравнивать постгрес дефолтный и от цаландо. Надо сравнивать цаландо против кластерный постгрес с патрони
  2. зависит от хранилки и настроек сети. Уверен, что потюнить постгрес в кубе, чтобы он работал побыстрее. Я уж не говорю, что под постгрес в кубе надо ОТДЕЛЬНЫЕ НОДЫ кучера
я постарался упростить насколько мог —
и там и там по одной ноде
диск выдавал локальный.
ресурсы тоже одинаковые(в заландо реквестами выставлял)

по различиям:
zalano ставил внутри кластера openshift, соотвественно ОС — fcos, вместо докера — cri-o.
обычный инстанс был на centos7.

в итоге вышло
ВМ: 402 tps
zalando: 154 tps

есть мнение что проблема на самом деле как раз в лимитах куба, где то на хабре была статья, что лимит может вызывать тротлинг цпу даже когда до планки еще далеко. но в заландо я на тот момент не нашел как это отключить.
другой вариант — локальный диск отдавал контейнеру через local storage operator, и че он с ним там делает — большой вопрос. есть шанс, что была двойная запись.

Спасибо за уточнение. tps меняли из контейнера с постгресом или как-то по-другому (снаружи кластера)? Возможно, что дело в этом

создавал третью вм и мерял поочередно.
при этом было подозрение на сеть, так что на самом деле для заландо делал два измерения:
через VIP (keepalive operator, прямо на сервис шифта вешал IP) — вышло 154 tps
через NodePort — вышло 145 tps

виртуальные диски располагались физически на одном ssd, полагаю, можно считать, что они были идентичны.

повторюсь, я не сильно шибко разбираюсь в постгре, вероятно я просто не умею его настраивать.

по keepalive operator у редхата: www.openshift.com/blog/self-hosted-load-balancer-for-openshift-an-operator-based-approach

попробуйте pgbench или что там у вас запустить прямо из контейнера с постгресом, чтобы исключить сеть. Это будет не очень честное сравнение, но по крайней мере — точно 'сырые' цифры. Или еще лучше — развернуть в опеншифте отдельный пг, не через цаландо и посмотреть его.

Ну лимиты могут повлиять. Но их можно задать сильно выше, чтобы покрывать все ядра VM. Ну и параметры запуска pgbench интересно увидеть.
А KubeDB не рассматривали вроде много баз помимо Postgres умеет.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.