Комментарии 3
А где хранится сама база данных? Прямо внутри контейнеров? Т.е. если рухнут одновременно все три пода то информация будет потеряна?
Сама база хранится на персистентном внешнем хранилище, которое подключается к поду. Хранилище должно быть свое отдельное у каждой реплики.
Но надо добавить что монга в кубернетесе это и помимо вот этого вопроса про хранилища — много боли.
Если вы как следует не настроите лимиты на других подах и монго подах, кубернетес может неожиданно начать ронять реплики с целью перенести их на менее загруженную ноду, а если учесть что монга сама по себе как бы не стейтлесс, операция освобождения и последующего захвата внешнего хранилища занимает время, особенно при аварийном выключении пода, переключение мастера в монге при убранном кубернетесом праймари на реальном железе может занимать десятки секунд — сильно рискуете ловить интересные спецеффекты в продакшене. Лимиты причем интересны не только по CPU но и по IO.
Скорее всего в итоге (при наличии большой и требовательной к IO монги в большом и требовательном к IO сервисе) придете к тому, что монга у вас будет хоть и в кубернетесе, но в собственном нодпуле, чтобы ни дай б-г какой-то другой под помешал ей функционировать и при обновлении этого нодпула до новой версии кубернетеса один фиг придется руками stepDown делать на primary чтобы максимально безболезненно «ребут» пережить.
Короче польза от переноса монги в кубернетес — она очень сильно зависит от ваших целей. Единообразие и удобство для девопсов, может быть. Безопасность (опять же единообразная с networkPolicies), упрощенный сетевой роутинг у сервиса, переносимость — наверное все-таки больше да чем нет.
Reliability — наверное все-таки больше нет, чем да.
Если вы как следует не настроите лимиты на других подах и монго подах, кубернетес может неожиданно начать ронять реплики с целью перенести их на менее загруженную ноду, а если учесть что монга сама по себе как бы не стейтлесс, операция освобождения и последующего захвата внешнего хранилища занимает время, особенно при аварийном выключении пода, переключение мастера в монге при убранном кубернетесом праймари на реальном железе может занимать десятки секунд — сильно рискуете ловить интересные спецеффекты в продакшене. Лимиты причем интересны не только по CPU но и по IO.
Скорее всего в итоге (при наличии большой и требовательной к IO монги в большом и требовательном к IO сервисе) придете к тому, что монга у вас будет хоть и в кубернетесе, но в собственном нодпуле, чтобы ни дай б-г какой-то другой под помешал ей функционировать и при обновлении этого нодпула до новой версии кубернетеса один фиг придется руками stepDown делать на primary чтобы максимально безболезненно «ребут» пережить.
Короче польза от переноса монги в кубернетес — она очень сильно зависит от ваших целей. Единообразие и удобство для девопсов, может быть. Безопасность (опять же единообразная с networkPolicies), упрощенный сетевой роутинг у сервиса, переносимость — наверное все-таки больше да чем нет.
Reliability — наверное все-таки больше нет, чем да.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Беспростойная миграция MongoDB в Kubernetes