0 урок DevOps⁠⁠

Монолит - это здоровый кусок скомпиленного кода. Запихнуть в кубер можно, но не нужно. Например, jhipster в одном фэт джаре вместе с фронтом и беком, который выполняет как авторизацию так и апи запросы - самый яркий пример. В кубер пихается, но жрёт неприлично много ресурсов, толком не масштабируется и вообще нахрен там не нужен. Дабы пихнуть его в кубер надо распиливать на микросервисы, независимые друг от друга, а именно: фронт, авторизация, и по сути по микросервису на каждый апи колл. Тогда каждый можно масштабировать в зависимости от определенных условий, в том числе и реализовать полноценный service mesh с прозрачными транзакциями и трейсингом на базе той же связки linkerd+jaeger.

Микросервисы смертны и ещё как. Задача оркестратора (кубера) отслеживать их здоровье и поднимать/опускать/масштабировать в зависимости от проб и нагрузки.

Касаемо бд - нефиг вообще на проде держать stateful нагрузки в кубах. Они не про это. Бд прекрасно кластеризуются и живут вне кубера или предоставляются клауд провайдером по схеме SaaS. Для дев сред никто не мешает поднять под с той же постгрей, но нужно понимать что в любой момент это может наебнуться.

Кубы про stateless приложения, которые не зависят друг от друга и спокойно переживают рестарты/масштабирования.

Надеюсь, ответил на ваши вопросы.

Обоснуйте? Почему нельзя запустить монолит в кубере? Я такого не говорил, я сказал что это нежелательно. Хорошо спроектированная микросервисная архитектура не падает, при адекватном DR. Что из того что я сказал пиздеж? Если хоть 1 слово наврал, то согласен удалиться отсюда и больше не появляться, если же выясниться что нет то удаляетесь вы, идет?