Но со стороны инфры это были сервера, с эарлангом и цфенджином агентом

Крутящихся механизмов было по минимуму, меньше точек отказа

У меня вообще остались приятные впечатления от эрланге, хотя я ни разу не программист, но как-то саппортилось это все разумно, хотя, промисы - это наркомания) ну да, это заслуга инженеров, которые писали код, я их прогерами назвать не могу, это именно инженеры были

1. конечно, tiller. Которого, поидее, надо заводить несколько штук для нормального разграничения прав.

2. это куча дополнительных сущностей, которые, по факту, нахер не нужны. Это release, app version, revision и т.д. Мало того, что они не решают никакую проблему, так о них еще и куб ничего не знает. В итоге в хельм ты думаешь о релизе, а по факту в кластере у тебя деплоймент.

3. YAML-шаблонизация. Это прям полный атас. Вроде пишешь ты yaml, но надо думать о правилах go-шаблонизатора. В итоге добавлять какие-то либо условия в шаблон это лютая боль, потому что надо и правильные indent соблюсти, и сделать так чтобы читалось, но при этом и проходило правила гошного темлейтинга. И это прям боль, жесть и слезы. В итоге любой шаблон через пару итераций превращается в нечитабельное говно.

4. Хер изменишь готовый пакет. Вот взял я prometheus chart, а он рассчитан исключительно на работу по домену и там в ingress вшито поле host, а оно мне не надо, я хочу юзать IP от GCP и все. Но этого я сделать уже не смогу, потому что YAML-шаблонизируется, а не генерируется. Можно попытаться форкнуть чарт и добавить туда условие, которое позволит юзать ip, вместо домена, что будет довольно сложно, потому что в шаблоне и так много логики. Но даже если ты это сделаешь, ты превратишь в нечитабельное и сложноподдерживаемое говнище, которым, он, в общем-то, является и так, даже и без этого условия.

5. Необходимость размазывать параметры по разным чартам, чтобы их переопределять. В разных окружениях приложение должно запускаться с разными параметрами. Для этого, как правило, создается chart окружения, в котором все перезаписывается. Лежит он, ест-но, где-то в стороне. Получается, что он выходит из под ответственности команды, которая отвечает за сервис, потому что конфигурация теперь не у них.  А хочется чтобы команда, которая пилит сервис, у себя могла описать все необходимые параметры для всех окружений, полностью отвечать за настройку сервиса и определять где, что и как должно быть. Kapitan, например, эту проблему решает через описание в "пакете"  параметров для всех окружений, а сам пакет в репе с приложением. Все чудно, вся настройка в руках у команды, делает все что считает нужным и другим не мешает, ответственность не размазывается.

6. Нет единой точки правды. Где мне ее смотреть в helm? В чарте? Там нихрена не поймешь. В кубе? Он ничего не знает о сущностях хельма. В тиллере? В нем то что он применял, а не то что в кластере.

Да, helm сейчас "стандарт индустрии", но это не значит что это хороший инструмент и им нужно пользоваться.

Нужно, иначе на выходе будет невалидный yaml

А, не, теперь нормально работает и без indent. Хорошо, жизнь с helm стала на 0.5% лучше

Огромное спасибо за развернутый ответ!

давай в медиум заметку!

И на хабру

не, обойдутся

Мы отлайкаем

там всезнайкки всё знают

Норм. Пост про Rook то зашёл )

Точнее про то какое он дно

@aladmit спасяб)

Пока draft. Авторство сохранил. Подготовил аргументы к подущей беседе про helm с коллегами :D тож прям горит)

https://medium.com/@Frodox/summary-%D0%BF%D1%80%D0%BE-helm-85070cb394f4

там первый же человек несёт дичь