Использую, для стейтлес. Но есть задачи, по развёртыванию БД и очереди. На текущий момент, я пытаюсь найти оптимальное по бюджету решение, которое не будет черевато технологическими и эксплуатационными проблемами в будущем

Коллеги, подскажите пожалуйста как правильно организовать установку кластерного приллложения, через Job включение в кластер или еще как-то? ну чтобы не отрываясь - необходимо развернуть Consul, почему не использую официальный Helm chart - политика партии

?

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

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

ну тот же консуль развернуть 3 пода в кластере

берешь, и разворачивавешь ) насчет хельма - не надо его боятся

для пользователя боль, когда оператор рулит объектами через CRD и просто не прокидывает какие-то поля. А тебе они нужны. И приходится либо kubectl patch после установки оператора, причем тебе нужны патчи например для деплойментов, а установка объекта это crd, который поднимает например деплоймент, и надо костылить ожидание появления именно деплойментов.
Ну либо PR отправлять разрабу оператора. Вот недавно как раз отправлял PR на redis spotahome, банально ради поля priorityClassName

я его не боюсь и с него все ставится - политика отдела - не использовать чарт

инфра какая ?

Использую, для стейтлес. Но есть задачи, по развёртыванию БД и очереди. На текущий момент, я пытаюсь найти оптимальное по бюджету решение, которое не будет черевато технологическими и эксплуатационными проблемами в будущем

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

Виртуалки vmware, на которых поднят кубер

сделай template и поправь нужные тебе поля )

Костыли? Да.
Что бы крутить стейтфул в кубе для этого должна быть веская причина. Например если вы деплоите его много или часто.

Но для этого hostPath обычно недостаточно и желательно иметь какой-нибудь storage-провижионер.

Из простого есть rancher/local-path-provisioner и nfs-client-provisioner

из того что посложнее: linstor, ceph и другие

Как не наступить на грабли: Нужно чётко понимать как ваша база будет работать и как её чинить если она вдуг сломается.

Банальный пример: Под с базой данных не стартует. Ваши действия?