Helm: менеджер пакетов для Kubernetes от Deis

В октябре мы разбирались с namespaces и радовались что наконец-то разделили dev, staging и prod в одном кластере. Потом пришло осознание: одно приложение теперь надо развернуть в три namespaces. А у нас три клиентских проекта. Умножаем - и понимаем что вручную поддерживать комплекты YAML-манифестов на каждую комбинацию проект-окружение довольно утомительно. Именно в этот момент Deis анонсировал Helm.

Проблема которую мы уже почувствовали

Типичная картина: есть Deployment, Service, ConfigMap, иногда Ingress. Для одного приложения в одном namespace - четыре файла YAML. Для трёх namespaces - двенадцать файлов, из которых отличается в основном namespace: и несколько значений вроде replica count или имени образа. Остальное - копипаст.

Мы какое-то время жили с этим через Ansible-роли: шаблоны Jinja2 подставляли значения, задача применяла манифесты через kubectl apply. Работало, но ощущение что Ansible делает чужую работу - не проходило. Kubernetes уже понимает desired state, зачем ещё один слой шаблонизатора поверх?

Что такое Helm

Helm вводит понятие Chart - это директория с шаблонами манифестов и файлом Chart.yaml с метаданными. Шаблоны написаны на Go template, переменные лежат в values.yaml. Выглядит примерно так:

myapp/
  Chart.yaml
  values.yaml
  templates/
    deployment.yaml
    service.yaml
    configmap.yaml

values.yaml - это набор дефолтных значений. При установке их можно переопределить флагом --set или отдельным файлом. Команда установки:

helm install myapp/ --set namespace=staging,replicas=3

Вместо того чтобы держать три комплекта YAML - держишь один Chart и три файла переменных. Разворачивать staging отдельно от prod становится вопросом одной команды с нужным values-staging.yaml.

Что попробовали на практике

Взяли одно из наших managed-приложений - веб-сервис с тремя компонентами: фронтенд, API, воркер. Раньше каждый компонент жил в отдельном наборе YAML-файлов, итого около 15 манифестов только для prod. Переупаковали в Chart за примерно два часа.

Первое что оценили - values.yaml как явная точка документации. Раньше чтобы понять «какой image tag сейчас в staging» надо было найти нужный файл и посмотреть. Теперь есть один файл переменных на окружение, и это он.

Второе - helm upgrade. Когда нужно обновить образ - не надо искать где именно в каком YAML прописан тег. Передаёшь --set image.tag=v1.42 и Helm обновляет что нужно. Rollback через helm rollback откатывает релиз к предыдущему состоянию.

Где споткнулись

Helm сейчас в ранней стадии, и это чувствуется.

Шаблонизация через Go template - местами неудобна. Условные блоки выглядят громоздко, и если шаблон разрастается - читаемость падает. Ansible-шаблоны на Jinja2 в этом плане привычнее.

Нет нормального Chart-репозитория. Для Ansible есть Galaxy с готовыми ролями - для Helm пока только набор примеров в репозитории на GitHub. Приходится писать Charts самим с нуля. Это не проблема когда Charts уже написаны, но на первый раз надо потратить время.

Управление секретами. В values.yaml нельзя хранить пароли и токены в открытом виде. Пока решаем это через отдельные Kubernetes Secrets, которые создаются вне Helm и монтируются в под через ссылку в Chart. Не идеально, но работает.

Права доступа. Helm в текущей версии работает без аутентификации - любой кто может запустить helm install получает доступ к кластеру через kubectl. Для наших managed-окружений это значит что Helm пока используется только на dev и staging, где у разработчиков и так есть доступ к кластеру.

Где мы сейчас

Charts для трёх приложений написаны и работают в dev и staging. Разворачивать новое окружение стало заметно быстрее - примерно десять минут вместо того чтобы копировать и редактировать пачку файлов.

В prod Helm не пошёл: там пока накатываем через kubectl apply по проверенным манифестам. Когда разберёмся с вопросом прав и секретов - будем думать дальше.

Идея правильная. Kubernetes-манифесты для сложного приложения - это много YAML, и без параметризации это превращается в головную боль при масштабировании. Chart как единица деплоя, values как конфигурация окружения - это то что нужно. Инструмент молодой и шероховатостей хватает, но направление понятное.

Если кто-то из команды уже пишет Charts или нашёл решение для секретов в Helm - расскажите, интересно как другие с этим справляются.