Переобуваемся в helm на лету: опыт группы DevOps Юлы 🔥

Как мы решали задачу переехать в новый Kubernetes всего за неделю и попутно начали использовать helm в команде?

Изначально мы выбрали подход написания чартов для каждого сервиса и раздачи в репозитории командам. Однако когда появилась необходимость вносить глобальные правки – мы столкнулись с проблемой. Исправление ошибки с lowercase-ом gitlab-ветки в имени деплоймента или изменения в кронджобах превращались в «9 кругов ада» из-за ручных исправлений в десятках репозиториев.
Чувствуете будущую боль поддержки этого счастья? После нескольких подобных кейсов, мы поняли что не готовы работать в режиме ручной поддержки решений и задумались об использовании helm.

Почему именно helm?
1️⃣ Получаем всегда актуальный набор манифестов для каждого сервиса: helm дает простую установку и удаление всех связанных куберовских сущностей.

2️⃣ Унифицированные, структурированные и понятные манифесты, которые после генерации удобно читать. Когда ваши yaml-манифесты для куба разрастаются, то становится сложно уследить за всеми зависимостями: вмешивается человеческий фактор, способный сломать сервис. Человек может забыть заменить, например, порт в виртуальном сервисе gloo.

3️⃣ Версионирование по веткам с возможностью откатить релиз, если что-то пошло не так при апдейте.

В следующей части расскажем о том, как внедрили helm.