Postgres в Kubernetes-е

Если память мне не изменяет, в темах за последний год был человек (ник не помню), который прод-проблемы с БД в кубере решал (с его слов).

Некоторые не советуют такое сочетание, но серьёзных аргументов я >не увидел, похоже на карго-культ

Ну бывают базы, а бывают БАЗЫ ДАННЫХ. Оно неровное движение kubectl и.

Кое-где еще DBM/DBA in person встречаются )

Так можно сказать, что одно неловкое движение terraform и. Не надо делать неловких движений)

Так можно сказать, что одно неловкое движение terraform и. Не >надо делать неловких движений)

Вот-вот. Разные зоны ответственности

Не пробовал, но проходил курс по Kubernetes от slurm.io, в Mega-части курса этот вопрос упоминается. Вкратце их аргументы:

• Развертывать в Kubernetes всякие тестовые базы, которым можно тормозить, и которые все равно пересоздадут в пустом виде - самое милое дело.
• Может возникнуть проблема с подбором персонала, так как управление базой осуществляется не напрямую, а через оператор, с которым спец по PostgreSQL работать не умеет, и предсказать реакцию которого на шаги по ручному устранению проблем не может.
• Точно возникнет проблема с производительностью, так как PersistentVolume будут на каком-нибудь Ceph’е, а из него больше 2500 IOPS в один поток выжать очень сложно. Для справки: база из-за своей транзакционности является по сути однопоточным клиентом. Из локального NVMe, даже из дешевого, можно выжать и 100000 IOPS. Да, есть CSI-модуль, который делает PersistentVolume из локальных каталогов, но тогда получается привязка к конкретному хосту, и, спрашивается, затем тогда Kubernetes?
• Точно возникнет проблема с быстродействием от соседних Pod’ов, которые будут, например, есть память и мешать кешировать диск. Да, можно поиграться с taints и tolerations, чтобы прибить базу на конкретный хост, где больше ничего нет, но зачем тогда Kubernetes?
• Есть такая замена Postgres’у, называется CockroachDB, которая умеет нативно в Kubernetes’е делать из себя кластер, и с которой у Slurm’а даже что-то хорошее на не сильно нагруженном проекте получилось.

Конкретно этот урок был практически без изменений продублирован в виде лекции на митапе «Stateful-приложения в 2020 году». Ссылка: https://highload.ru/2020/slurm-meetup/watch, или на youtube с привязкой ко времени, чтобы не проматывать пустоту: https://youtu.be/ykIh4-616Ic?t=2034

Спасибо!

Точно возникнет проблема с производительностью, так как PersistentVolume будут на каком-нибудь Ceph’е, а из него больше 2500 IOPS в один поток выжать очень сложно. Для справки: база из-за своей транзакционности является по сути однопоточным клиентом. Из локального NVMe, даже из дешевого, можно выжать и 100000 IOPS. Да, есть CSI-модуль, который делает PersistentVolume из локальных каталогов, но тогда получается привязка к конкретному хосту, и, спрашивается, затем тогда Kubernetes?

Хостер обещает 12800/6400 IOPS на чтение/запись через SAN. Альтернатива постгресу в настоящий момент - крутить базу на той же виртуалке с тем же подключенным томом. Локальных NVME дисков не дают. Но в целом мы сейчас в БД далеко не упираемся. Собственно в настоящий момент базы крутятся в самопальных докер-контейнерах на HDD, поэтому тут проблем я не ожидаю.

Точно возникнет проблема с быстродействием от соседних Pod’ов, которые будут, например, есть память и мешать кешировать диск. Да, можно поиграться с taints и tolerations, чтобы прибить базу на конкретный хост, где больше ничего нет, но зачем тогда Kubernetes?

А разве нельзя в кубернетесе указать, сколько ресурсов должно быть гарантировано Pod-у, и он обеспечит, чтобы они были доступны?

Есть такая замена Postgres’у, называется CockroachDB, которая умеет нативно в Kubernetes’е делать из себя кластер, и с которой у Slurm’а даже что-то хорошее на не сильно нагруженном проекте получилось.

Интересно, надо будет исследовать этот вопрос.

https://youtu.be/ykIh4-616Ic?t=2034

Ещё раз спасибо, будем посмотреть.

https://www.youtube.com/watch?v=BnegHj53pW4&t=2729s

Вот тут очень хорошо Дима все рассказывает.

Хостер обещает 12800/6400 IOPS на чтение/запись через SAN

А это советую побенчмаркать через fio. Возможно, цифра валидна только для многопоточных клиентов. Но не упираетесь - и хорошо.

А разве нельзя в кубернетесе указать, сколько ресурсов должно быть гарантировано Pod-у, и он обеспечит, чтобы они были доступны?

Kubernetes толком не поддерживает такой ресурс, как память, неявно выделенная ядром под дисковый кеш. А для баз это важно.

Это не обычная для кубера программа. Основной концепт кубера в том что он предназначен для stateless сервисов, который если умрет, то и пофиг, его можно перезапустить, возможно даже на другой ноде. Также такие сервисы легко масштабировать. Когда дело доходит до stateful сервисов, то концепт кубера разваливается. Да, для них сделаны костыли всяческие в виде stateful set и persistent volume, но это не отменяет фундаментального ограничения - данные на хранилище копировать между нодами долго.

6400 iops выглядит все ещё больше чем может hdd выдать, но надо посмотреть в каких условиях достигается эта цифра. Может там 64 потока с глубиной очереди 128.

А в целом, нафига оно тебе? Вот этот тюнинг лимитов ресурсов, персистент волюмы? Зарядил 2-3 виртуалки или даже на bare metal в репликации, а сверху пгбаунсер, его можно уже в кубер закинуть

Kubernetes толком не поддерживает такой ресурс, как память, неявно выделенная ядром под дисковый кеш. А для баз это важно.

Спасибо, интересная мысль, про неё не думал. Но в целом кроме баз все остальные сервисы обычно с диском особо не работают. Поэтому полагаю, что если обеспечить на ноде не более одного пода, активно работающего с диском и нужного объёма зарезервированной памяти, то вроде как должно быть нормально.

Это не обычная для кубера программа. Основной концепт кубера в том что он предназначен для stateless сервисов, который если умрет, то и пофиг, его можно перезапустить, возможно даже на другой ноде. Также такие сервисы легко масштабировать. Когда дело доходит до stateful сервисов, то концепт кубера разваливается. Да, для них сделаны костыли всяческие в виде stateful set и persistent volume, но это не отменяет фундаментального ограничения - данные на хранилище копировать между нодами долго.

Ну я тут не согласен. Почему костыли-то? Все инструменты есть для этого. Чего он умирать просто так будет-то. Если сервер умрёт, то он где хочешь умрёт.

А в целом, нафига оно тебе? Вот этот тюнинг лимитов ресурсов, персистент волюмы? Зарядил 2-3 виртуалки или даже на bare metal в репликации, а сверху пгбаунсер, его можно уже в кубер закинуть

Во-первых я не админ. Поэтому подход, когда всё, что связано с админством и можно минимизировать и переложить на плечи автоматики, которую ещё и не мне писать, я приветствую. Постгрес операторы обещают именно это. Сейчас у нас в компании с админством всё плохо и я пытаюсь это исправить не становясь, собственно, выделенным админом. Тот же постгрес, который у нас стоит, никто не апгрейдит и не собирался, пока я этот вопрос не поднял. А это не правильно. Оператор этот вопрос в моём понимании решает.

Во-вторых кубернетес помогает экономить ресурсы, ужимая всё на нужное число нод. А не так, что отдельная машина на постгрес, который её может даже на половину не будет использовать. С другой стороны при необходимости можно нарастить ноды. Что недавно происходило - повысилась нагрузка на систему, которая стоит на железных серверах, а железных серверов нет и возможности их заказать быстро нет. В итоге пытались ужаться по максимуму что-то там руками ковыряя. Если бы можно было на неделю включить 2 виртуальных сервера, потратив на это 10 минут, а потом их выключить, это было бы благо.

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

Сразу скажу, что я понимаю, что в такой ситуации правильно использовать managed базы, а не самому с этим всем ковыряться, но такой возможности пока нет.

Есть такая замена Postgres’у, называется CockroachDB, которая >умеет нативно в Kubernetes’е делать из себя кластер, и с которой >у Slurm’а даже что-то хорошее на не сильно нагруженном проекте >получилось.

вот да, были проекты, суют My / Pg туда, где и sqlite overkill )

Основной концепт кубера в том что он предназначен для stateless сервисов, который если умрет, то и пофиг, его можно перезапустить, возможно даже на другой ноде.

я не знал что такое k8s пока вы не объяснили

я писал такую booty, которая делает загрузочный дистрибутив в tmpfs, тоже stateless.

чож получается, я k8s изобрёл?

вот енто да..

Если у тебя там до кучи есть балансировка, масштабирование, отказоустойчивость, удобство конфигурации, zero downtime апгрейды, то получается да, жму твою мужественную руку!

Для разработки, тестов и прочего где сохранность данных не важна используйте базу в кубер, проблем нет. Для прода, если вам сколько нибудь ценны данные хранящиеся в базе - лучше не надо

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

По опыту, согласиться с этим в случае со «слоеной» схемой не могу. Т.е. вот ты управляешь оператором, а оператор управляет кластером из Postgres’ов. Абсолютно все слои абстракции - дырявые. Если что-то сломается, то тебе придется отлаживать как саму базу, так и оператор, т.е. работы будет больше, и учить в авральном режиме придется еще больше. В качестве примера-аналога посмотри на LOR’е все эти треды, когда у пользователей звук ведет себя не так - приходится отлаживать как PulseAudio (который заявляет, что абстрагирует всякие сложности ALSA и добавляет сверху функциональность), так и, внимание, саму ALSA и еще взаимодействие между ними.

Если что-то сломается, то тебе придется отлаживать как саму базу, >так и оператор, т.е. работы будет больше, и учить в авральном >режиме придется еще больше.

+1

ну еще базу могут использовать больше одного проекта, которые даже не знают (или не должны знать) друг о друге )

предназначен для stateless сервисов, который если умрет, то и >пофиг, его можно перезапустить, возможно даже на другой ноде

Вот, кстати, хороший хинт для девелоперов )

Если пофиг, что умрет persistent база при пересборке IaC, значит она там не нужна )))

экономить ресурсы, ужимая всё на нужное число нод. А не так, что >отдельная машина на постгрес, который её может даже на половину >не будет использовать. С другой стороны при необходимости можно >нарастить ноды. Что недавно происходило - повысилась нагрузка на >систему, которая стоит на железных серверах, а железных серверов >нет и возможности их заказать быстро нет. В итоге пытались >ужаться по максимуму что-то там руками ковыряя. Если бы можно >было на неделю включить 2 виртуальных сервера, потратив на это 10 >минут, а потом их выключить, это было бы благо.

^^^

у вас либо мало ресурсов,

либо много:

хотел одним кликом поднимать всё окружение на каждую ветку для >каждого разработчика, с полностью независимыми базами и всем >остальным. Чтобы он писал себе код, тестировал и тд, ни с кем не >пересекаясь. Единообразное управление базами в том числе нужно и >для этого.

тестировать должен робот в staging(1..N) environment и только перед продом - человек(и)

PS может быть много разработчиков на многих ветках, которые даже не знают что делают другие

но зачем тогда Kubernetes?

Чтобы гонять всю нагрузку в одном месте и настройки все держать в одном месте, и даже CI/CD pipeline чтобы был одинаковый. Т.е. банально уменьшить количество вещей, о которых должен помнить админ.

кубера в том что он предназначен для stateless сервисов

Возможно, вам будет интересно ознакомиться с https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

Еще вот это прорекламировали на Hacker News: https://github.com/CrunchyData/postgres-operator

Осторожно - лицензионная ловушка! Использовать контейнеры Crunchy Data в production запрещено лицензией.

https://hub.docker.com/r/crunchydata/crunchy-postgres: «This container is maintained by Crunchy Data and is provided under the Crunchy Data Developer Program.»

https://www.crunchydata.com/developers/terms-of-use: «For avoidance of confusion, the Crunchy Developer Software without an active Crunchy Data Support Subscription or other signed written agreement with Crunchy Data are not intended for: using the services provided under the Program (or any part of the services) for a production environment, production applications or with production data»

Для прода, если вам сколько нибудь ценны данные хранящиеся в базе - лучше не надо

А как можно потерять данные при правильно работающем бэкапе с архивными логами транзакций?

IMHO вопрос только в соблюдении SLA, что зависит в основном от опыта работы с Кубером?

Точно возникнет проблема с производительностью, так как PersistentVolume будут на каком-нибудь Ceph’е, а из него больше 2500 IOPS в один поток выжать очень сложно.

Бывают ведь и более производительные HA хранилища данных? Например, Linstor? Только зачем HA хранилище для кластера СУБД, который сам умеет в HA на обычных хранилищах (речь о табличных пространствах для РСУБД или аналогах для NoSQL СУБД)? Оператор можно настроить для работы с разными НЕ HA хранилищами для каждого отдельно взятого узла? Проброс по iSCSI и через другие подобные Кубер провайдеры? Контейнеру обязательно пользоваться наружным томом, предоставляемым Кубером? Сам он не может смонтировать себе хранилище по сетке только внутри себя именно под табличные пространства?

Использовать контейнеры Crunchy Data в production запрещено лицензией.

С их поддержкой же незапрещено?

Причем речь идет о «not intended» - непредназначено, а не запрещено? Т.е. они как бы намекают, что не рекомендуют без платной поддержки даже пытаться? :)

Переформулирую:

А как можно потерять данные при правильно работающем бэкапе с архивными логами транзакций по крайне мере для full ACID РСУБД с синхронными репликами?

Хотя возможно, в случае использования BASE СУБД с eventual consistency не все так радужно?