БД и Микросервис в одном pod, но разных контейнерах — хорошо или нет?

Question

[oywemy]

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

K8S( WorkingNode( Pod( Container(Логика), Container(База данных) ) ) )

Answer 1

[d-stream]

Обычно подразумевается что микросервис/под - это одноразовая рыбка без памяти. В любой момент экземпляр микросервиса может быть убит и трафик будет передан другому экземпляру например в другом месте (нода, локация и т.п.). Грубо следует ориентироваться что сервис обслуживает один запрос и мрёт.

А вот база данных - долговременное (постоянное, надёжное) хранение данных. Если говорить о популярных реляционных СУБД, то на сегодня это с большой вероятностью - postgress
То что касается "изоляции" данных разных микросервисов - у него уже всё есть. К примеру в его терминах "каждому микросервису по базе данных" - это "каждому микросервису по схеме" (ибо БД растяжимое понятие и database в терминах pg - это чуть иное) притом естественно к каждой схеме отдельная УЗ (роль)

Comments

[oywemy]

Стоит выносить базу данных на уровень отдельно пода, ноды или вообще вне кластера на другом сервере?

[Василий Банников]

oywemy, если держать в кубере, то лучше взять готовый оператор / дистрибутив постгреса специально для кубера. Просто в лоб в поду кидать или изобретать велосипед не стоит.

[d-stream]

Для более "понятного" и прозрачного варианта - лучше виртуалку/baremetal сервер. То бишь вне кубера.
Хотя бы с точки зрения что БД - это в первую голову производительная дисковая подсистема, а нодам кубера это можно сказать малокритично -> всё что кубер обычно строится на дисковых системах сортом пониже.

[oywemy]

d-stream, понял что базу данных лучше выносить на отдельные железки, но можешь рассказать подробнее про "каждому микросервису по схеме"? Было бы понятно создавать просто базу данных в постгресе для микросервиса с отдельной для нее учеткой, но вот про схемы особо не нашел информации для чего это нужно (именно в этом контексте) - для изучения вопроса мог бы скинуть пару ссылок?

[d-stream]

oywemy,
В терминах pg:

server
- database
- schema
- tables, sequences, etc

то есть схема - как раз хорошая абстракция для "изоляции" индивидуальных связок таблиц для конкретного микросервиса (scope).
Да и DDL подразумевает например раздачу прав в виде

GRANT { { SELECT | INSERT | UPDATE | DELETE | TRUNCATE | REFERENCES | TRIGGER }
[, ...] | ALL [ PRIVILEGES ] }
ON { [ TABLE ] table_name [, ...]
| ALL TABLES IN SCHEMA schema_name [, ...] }
TO role_specification [, ...] [ WITH GRANT OPTION ]
[ GRANTED BY role_specification ]

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

[oywemy]

d-stream, есть ли смысл создавать тогда разные database для каждого микросервиса? Просто создать одну базу и под каждый сервис свою схему?

[d-stream]

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

Answer 2

[Alexey Dmitriev]

Для постоянных вещей типа СУБД придумали statefulset - его и нужно использовать. И отдельно от приложения.

Answer 3

[lotary]

Звучит как костыль)) почему нельзя базу данных запустить отдельно? Так получается, что при обновлении пода перезапускается и база данных. Да и вообще можно использовать один инстанс базы, с разными схемами для различных микросервисов. Если же нужны разные базы для разных микросервисов, то изолировать можно через Network Policies.

Comments

[oywemy]

Запускать базу данных стоит вне кластера k8s или просто в отдельном pod будет достаточно?

[lotary]

Тут смотря что от нее нужно, и какая нагрузка ожидается. Правило одно: база на выделенном сервере будет работать быстрее, но за ней нужно смотреть больше (рейд для дисков, желательно еще реплику добавить если что-то произойдет с сервером)