Всем доброе утро! Планируем переход на кубернетес в проде и деве,

основной вопрос как организовать базы данных при маштабируемых сервисах? Т.е. Какие бест практикс подходы используют? Выносят базы отдельно? В кубере? (если да, то как организовывается передача хранилища бд между нодами?)

Ну не у девопсов же это спрашивать. https://t.me/itarchitect

Речь про кубер в частности) у кого как устроено, поделятся люди добрые)

базы закрепляется на конкретные ноды, используют local volumes, request/limits выставляются по максимум по ноде, вешаются taints чтобы туда не заезжали другие поды, ну это если мы про нормальную нагрузку говорим . Все решения с сетевым стораджем медленные и вообще зависит от твоей сети сильно, есть ли 10гбит сети? можно ли под трафик сетевого стораджа выделить отдельный сетевой интерфейс? Надо тестировать хватает ли такой производительности.

Спасибо! А если нода где расположен под выходит из строя, а база на local volumes, то как решаете?

Штатные механизмы отказоустойчивости в СУБД. А как вы думаете куб вам отказоустойчивость обеспечит? Давайте рассмотрим ситуацию: 1) Нода падает, в течении ~40 секунд (не меньше) kubernetes понимает что нода упала, и помечает ее как notReady 2) Затем в зависимости от настроек, но по умолчанию это 300 секунд, kubernetes начнет выселять от туда поды 3) ТОЛЬКО если база данных была в deployment, то под с ней переедет на новую ноду в течении какого-то неопределенного времени (зависит от многих факторов + фактор как быстро подниметься база, а может вообще не подняться так как нода резко отказала, проццесс СУБД завершился некорректно, бинарные данные базы могут быть испорчены, и придется вручную восстанавливать (ну это самый плохой вариант)) Если же база поднята в statefulset, то под с базой в случае отказа ноды вообще никуда не уедет, без вручного вмешательства, также для того чтобы избежать сплитбрейна, придется огранизовать какое-то добивание ноды, дабы минимизировать вероятность сплитбрейна и корапта данных. В итоге мы получаем минимальный простой ~ 6 минут, конечно можно подкрутить некоторые таймауты, но это всегда история о компромисах. Например слишком маленький таймаут, может обеспечить ложные срабатывания на выселение подов из ноды, что тоже нехорошо. Отсюда следует, что штатные механизмы отказоустойчивости СУБД необходимы, и без разницы где вы крутете базы данных, в kubernetes или нет. Сам kubernetes может гарантировать только возможность поднятия подов на других нодах, если нода стала недоступна, и конечно это происходит не моментально - это механизм оркестрации, а не отказоустойчивости. Даже в случае с сетевыми стораджами, вам все равно будет нужна отказоустойчивость на уровне СУБД. Если конечно вы не согласуете с бизнесом что простои базы в случае отказов нод это норм.

К слову это прям эталонный случай применения patroni для того же постгреса

так это механизм отказоустойчивости для postgres. Это же не куб вам сам отказоустойчиовсть обеспечил. Тот же patroni можно и без куба крутить. Защита от сплитбрейна, в механизмах отказоустойчивости имеется, но куб к этому никакого отношения не имеет.

А тут именно в контексте куба вопрос был

yep

Большое спасибо за развернутый ответ! В таком случае держать базу данных в системе оркестрации особо нет получается...

кому есть, кому нет. Зависит от вкусов

Ок, спасибо!