История изменений

Это не обычная для кубера программа. Основной концепт кубера в том что он предназначен для stateless сервисов, который если умрет, то и пофиг, его можно перезапустить, возможно даже на другой ноде. Также такие сервисы легко масштабировать. Когда дело доходит до stateful сервисов, то концепт кубера разваливается. Да, для них сделаны костыли всяческие в виде stateful set и persistent volume, но это не отменяет фундаментального ограничения - данные на хранилище копировать между нодами долго.

Ну я тут не согласен. Почему костыли-то? Все инструменты есть для этого. Чего он умирать просто так будет-то. Если сервер умрёт, то он где хочешь умрёт.

А в целом, нафига оно тебе? Вот этот тюнинг лимитов ресурсов, персистент волюмы? Зарядил 2-3 виртуалки или даже на bare metal в репликации, а сверху пгбаунсер, его можно уже в кубер закинуть

Во-первых я не админ. Поэтому подход, когда всё, что связано с админством и можно минимизировать и переложить на плечи автоматики, которую ещё и не мне писать, я приветствую. Постгрес операторы обещают именно это. Сейчас у нас в компании с админством всё плохо и я пытаюсь это исправить не становясь, собственно, выделенным админом. Тот же постгрес, который у нас стоит, никто не апгрейдит и не собирался, пока я этот вопрос не поднял. А это не правильно. Оператор этот вопрос в моём понимании решает.

Во-вторых кубернетес помогает экономить ресурсы, ужимая всё на нужное число нод. А не так, что отдельная машина на постгрес, который её может даже на половину не будет использовать. С другой стороны при необходимости можно нарастить ноды. Что недавно происходило - повысилась нагрузка на систему, которая стоит на железных серверах, а железных серверов нет и возможности их заказать быстро нет. В итоге пытались ужаться по максимуму что-то там руками ковыряя. Если бы можно было на неделю включить 2 виртуальных сервера, потратив на это 10 минут, а потом их выключить, это было бы благо.

В моих мечтах я бы вообще хотел одним кликом поднимать всё окружение на каждую ветку для каждого разработчика, с полностью независимыми базами и всем остальным. Чтобы он писал себе код, тестировал и тд, ни с кем не пересекаясь. Единообразное управление базами в том числе нужно и для этого.

Сразу скажу, что я понимаю, что в такой ситуации правильно использовать managed базы, а не самому с этим всем ковыряться, но такой возможности пока нет.

Это не обычная для кубера программа. Основной концепт кубера в том что он предназначен для stateless сервисов, который если умрет, то и пофиг, его можно перезапустить, возможно даже на другой ноде. Также такие сервисы легко масштабировать. Когда дело доходит до stateful сервисов, то концепт кубера разваливается. Да, для них сделаны костыли всяческие в виде stateful set и persistent volume, но это не отменяет фундаментального ограничения - данные на хранилище копировать между нодами долго.

Ну я тут не согласен. Почему костыли-то? Все инструменты есть для этого. Чего он умирать просто так будет-то. Если сервер умрёт, то он где хочешь умрёт.

А в целом, нафига оно тебе? Вот этот тюнинг лимитов ресурсов, персистент волюмы? Зарядил 2-3 виртуалки или даже на bare metal в репликации, а сверху пгбаунсер, его можно уже в кубер закинуть

Во-первых я не админ. Поэтому подход, когда всё, что связано с админством и можно минимизировать и переложить на плечи автоматики, которую ещё и не мне писать, я приветствую. Постгрес операторы обещают именно это. Сейчас у нас в компании с админством всё плохо и я пытаюсь это исправить не становясь, собственно, выделенным админом. Тот же постгрес, который у нас стоит, никто не апгрейдит и не собирался, пока я этот вопрос не поднял. А это не правильно. Оператор этот вопрос в моём понимании решает.

Во-вторых кубернетес помогает экономить ресурсы, ужимая всё на нужное число нод. А не так, что отдельная машина на постгрес, который её может даже на половину не будет использовать. С другой стороны при необходимости можно нарастить ноды. Что недавно происходило - повысилась нагрузка на систему, которая стоит на железных серверах, а железных серверов нет и возможности их заказать быстро нет. В итоге пытались ужаться по максимуму что-то там руками ковыряя. Если бы можно было на неделю включить 2 виртуальных сервера, потратив на это 10 минут, а потом их выключить, это было бы благо.

Сразу скажу, что я понимаю, что в такой ситуации правильно использовать managed базы, а не самому с этим всем ковыряться, но такой возможности пока нет.