Как пользователь я предпочитаю Helm-чарты т.к.:
1) Я всегда могу видеть что происходит внутри
2) Если мне нужно что-то добавить или изменить, я могу легко этого сделать без пересборки docker-образа и прочей лабуды
3) Если разработчик чарта забухал, я или кто угодно может продолжить его разработку
(т.к. это всего-лишь пачка манифестов)
4) Большинство операторов расчитанно на деплой 1-3 копий приложения, когда таких копий становится сотни или даже тысячи операторы показывают себя далеко не с самой лудшей стороны.
5) CRD требуют cluster-admin прав
6) Со временем кластер оказывается под чистую засран всевозможными CRD и контроллерами для них. Тратится больше ресурсов, и этим зоопарком сложно управлять.

Как разработчик я предпочитаю Helm-чарты т.к.:
1) Наиболее простой инструмент, который есть у всех
2) Пользователи всегда могут видеть что применяется внутри (т.к. это всего-лишь пачка манифестов)
3) Если я условно забухаю, кто угодно сможет продолжить разработку

Если вы сами готовы тащить такое решение, и при этом сможете его поддерживать и чинить в случае поломок, то это не костыли, это уровень вашей компетенции.

Всем привет! Ребята, подскажите, пожалуйста, следующий момент. На сколько правильно использовать кубер для развёртывания базы данных (например postgresql) и kafka?
Есть ли опыт эксплуатации таких решений? В инете много статей о том, что кубер можно использовать только для развёртывания компонентов, которые не хранят состояния. Однако, есть статьи где рассказывается как к контейнерам можно подключать разделы хост-машины, чтобы обойти эти ограничения. Однако, многие devops считают эти решения костылями.
Действительно ли это костыли?

Кафку поставить отдельно и забыть

у меня тоже столон в кубере

Это не тот форум, и это вообще не так работает, но я намекну. Стабильный фреймрейт - задача разработчика игры. Хардвер там соответствует заявленному разработчикам. После конвертации в видеострим (специальным хардвером сжатия) количество кадров в секунду теряется... между 30, 60 и 120 большой разницы нет - когда смотришь 4к видео, точно ведь не знаешь, сколько кадров в секунду камерой снимали или рендерили. Бич этих платформ - лаг. Сидеть на гигабите в 2мс пинга от гугловкуого дата центра совсем не то же, что играть через спутник с маленького острова в Тихом океане,,: нажал "огонь" -через секунду выстрел. Но картинка не дёргается.

+ wal-g и можно не бояться

Как пользователь я предпочитаю Helm-чарты т.к.:
1) Я всегда могу видеть что происходит внутри
2) Если мне нужно что-то добавить или изменить, я могу легко этого сделать без пересборки docker-образа и прочей лабуды
3) Если разработчик чарта забухал, я или кто угодно может продолжить его разработку
(т.к. это всего-лишь пачка манифестов)
4) Большинство операторов расчитанно на деплой 1-3 копий приложения, когда таких копий становится сотни или даже тысячи операторы показывают себя далеко не с самой лудшей стороны.
5) CRD требуют cluster-admin прав
6) Со временем кластер оказывается под чистую засран всевозможными CRD и контроллерами для них. Тратится больше ресурсов, и этим зоопарком сложно управлять.

Как разработчик я предпочитаю Helm-чарты т.к.:
1) Наиболее простой инструмент, который есть у всех
2) Пользователи всегда могут видеть что применяется внутри (т.к. это всего-лишь пачка манифестов)
3) Если я условно забухаю, кто угодно сможет продолжить разработку

Всем привет! Ребята, подскажите, пожалуйста, следующий момент. На сколько правильно использовать кубер для развёртывания базы данных (например postgresql) и kafka?
Есть ли опыт эксплуатации таких решений? В инете много статей о том, что кубер можно использовать только для развёртывания компонентов, которые не хранят состояния. Однако, есть статьи где рассказывается как к контейнерам можно подключать разделы хост-машины, чтобы обойти эти ограничения. Однако, многие devops считают эти решения костылями.
Действительно ли это костыли?

Всем привет! Ребята, подскажите, пожалуйста, следующий момент. На сколько правильно использовать кубер для развёртывания базы данных (например postgresql) и kafka?
Есть ли опыт эксплуатации таких решений? В инете много статей о том, что кубер можно использовать только для развёртывания компонентов, которые не хранят состояния. Однако, есть статьи где рассказывается как к контейнерам можно подключать разделы хост-машины, чтобы обойти эти ограничения. Однако, многие devops считают эти решения костылями.
Действительно ли это костыли?

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