Ну есть базюки которые можно и в кубере катать, но вообще - а зачем бд в кубер пихать?
мб это мои потные фантазии про распределенные системы? или недостаток опыта
Ещё раз, что бы катать базки в кубе нужно чётко понимать зачем вам это нужно. Если у вас каждый день деплоятся новые базы и нужен нормальный провиженинг для них, то это тот самый кейс, когда, куб сгодится.
Ну вообщем то как написали выше - если нужно бд делать каждый день/час - да тогда имеет смысл когда у тебя одна бд на века - 0 смысла только оверхед и лишняя головная боль
Просто куб накладывает определенные ограничения учитывая которые, менеджить стейтфул может быть не так удобно. Например вам чётко нужно понимать как это работает, и как конкретно починить если что-то пошло не так.
понятно. а если много сервисов и много баз с долгим сроком жизни, то храниим их вне кластера?
Простейший пример: под с базой данных не стартует, логов не пишет, сразу умирает, что делать?
А есть разница бд это или нет?)
Ну в бд там данные лежат, например
имеется ввиду любой стейтфул ресурс, не только база конечно
Ну просто если у тебя тоже самое будет с подом стейтлес у тебя что другой траблшутинг включается?
Ну обычно стейтфул в кубе принято делать так, чтобы оно умело работать в несколько реплик и умирать отдельными подами. Но тут может прийти другая беда: Большинство приложений используют podManagementPolicy: Ordered (значение по умолчанию), это значит что поды должны запускаться поотчерёдно. То есть если самая первая реплика выходит из строя и вы случайно перезапустили какую-нибудь другую реплику, то ничего не заведётся пока вы не почините самую первую реплику
Как починить такой statefulset? Можно ли обновлять спеку в yaml?
В общем все эти моменты нужно понимать и принимать во внимание при запуске любого стейтфула в кубе.
Если все эти аспекты учесть, то выходит куб - это отличный инструмент как для stateless так и для stateful приложений, кто бы что не говорил
Обсуждают сегодня