HULL: Helm-чарты без шаблонов — вся конфигурация в values.yaml

Если вы писали Helm-чарты, то знаете этот ритуал: на каждый Deployment, Service, ConfigMap — свой файл в templates/, набитый {{ .Values.… }} и {{- if … }}. Для трёх ресурсов терпимо. Для двадцати — это стена копипасты, где легко ошибиться в отступе и тяжело ревьюить.

HULL (Helm Uniform Layer Library) предлагает другой подход: никаких кастомных шаблонов в templates/ — все объекты описываются в values.yaml. Ниже — что это, как устроено и, честно, где у подхода границы.

Это не перевод README, а мой разбор проекта. HULL — open source под лицензией Apache-2.0, автор — vidispine . Первоисточник и документация — в репозитории.

В чём идея

HULL — это библиотечный чарт (Helm library chart): сам по себе он ничего не разворачивает, а подключается как зависимость к вашему чарту и даёт набор шаблонных функций. Ваша роль сводится к декларации объектов в values.yaml под ключом hull.objects, а HULL превращает их в валидные Kubernetes-манифесты.

Практический эффект: в templates/ лежит один статический файл hull.yaml (копируется из HULL как есть и больше не трогается). Всё остальное — данные, а не код шаблонов.

Минимальный пример

Обычный nginx-Deployment на три реплики целиком описывается так:

hull:
  config:
    general:
      rbac: false
  objects:
    deployment:
      nginx:
        staticName: true
        replicas: 3
        pod:
          containers:
            nginx:
              image:
                repository: nginx
                tag: 1.14.2
              ports:
                http:
                  containerPort: 80

На выходе — стандартный Deployment с автоматически проставленными Kubernetes-лейблами и метаданными. Обратите внимание: контейнеры и порты — это словари с именами (nginx, http), а не списки. Это важное отличие HULL: именованные ключи вместо массивов — их проще переопределять и мёржить между слоями values.

Что HULL даёт сверх «просто YAML»

Если бы всё сводилось к «перенесли шаблон в values», смысла было бы немного. Реальная ценность — в четырёх вещах.

1. Полный доступ к Kubernetes API. Вы не ограничены подмножеством полей, которое «завёл автор чарта». Любое свойство объекта Kubernetes доступно напрямую — HULL не прячет API за упрощённым интерфейсом.

2. Иерархическое обогащение метаданными. Лейблы и аннотации можно задавать на нескольких уровнях — глобально, на тип объекта, на группу, на конкретный инстанс — и они складываются. Не нужно вручную дублировать общий набор лейблов в каждом ресурсе.

3. Трансформации — Go-шаблоны внутри values. Иногда чистых данных мало и нужна логика. HULL позволяет встраивать шаблонные выражения прямо в значения через префиксы _HT:

• _HT! — применить шаблонную функцию;
• _HT* — подставить значение из другого места конфига (например, _HT*hull.config.specific.field);
• _HT? — условный рендеринг.

Это компромисс: мощь Go-шаблонов остаётся доступной, но живёт в данных, а не в отдельных файлах.

4. Defaults и работа с ConfigMap/Secret. Через _HULL_OBJECT_TYPE_DEFAULT_ можно задать значения по умолчанию для всех объектов одного типа — меньше повторов. ConfigMap и Secret можно описывать инлайн или импортировать из внешних файлов (с автоматическим Base64), а также включать автоматическое хеширование — тогда при изменении конфига поды сами перезапустятся (частая ручная боль в обычных чартах).

Плюс — валидация по JSON Schema: подсказки в IDE и проверка манифестов против Kubernetes API ещё до деплоя.

Установка

HULL подключается как зависимость чарта, и один раз копируется статический hull.yaml в templates/ родительского чарта. Версии HULL привязаны к мажорным релизам Kubernetes (1.36, 1.35, 1.34 и т.д.) — поддерживаются три последних версии. Совместим с Helm 3 (3.1+) и Helm 4.

Честно: где границы подхода

«Уважать читателя» — это в том числе не продавать серебряную пулю. У HULL есть цена:

• Кривая обучения. Вы меняете один DSL (шаблоны Helm) на другой (модель HULL: objects/config, именованные словари, префиксы _HT). Команде придётся это выучить, и не весь опыт «обычного Helm» переносится.
• values.yaml разрастается. Вся конфигурация в одном дереве — для крупного приложения это большой файл. Плюсы (всё в одном месте) оборачиваются минусами (навигация, диффы, конфликты в git).
• Логика в данных. _HT-выражения — это по сути код внутри YAML. Когда его становится много, отлаживать «данные, которые на самом деле шаблон» бывает муторнее, чем честный .tpl.
• Привязка к модели HULL. Вы принимаете соглашения библиотеки. Съехать обратно на «ручные шаблоны» — это переписывание.

Когда стоит и когда нет

Стоит попробовать, если:

• у вас много однотипных чартов и надоела копипаста шаблонов;
• нужен полный доступ к Kubernetes API без «обёрток» автора чарта;
• цените консистентные метаданные и валидацию до деплоя;
• команда готова вложиться в единый подход.

Скорее не стоит, если:

• чарт маленький и простой — overhead HULL не окупится;
• команда не готова к новому DSL, а Helm-шаблоны все уже знают;
• вам важна нулевая «магия» между values и итоговым манифестом при отладке.

Итог

HULL — это не «Helm попроще», а другой способ мыслить о чартах: объект Kubernetes как данные, а не как текстовый шаблон. На парке однотипных сервисов это убирает тонну boilerplate и делает метаданные и валидацию единообразными. Но это инструмент с характером — с собственной моделью, которую надо принять целиком. Стоит завести тестовый чарт, собрать на нём пару реальных объектов и решить на практике, ложится ли подход на вашу команду.

Первоисточник, документация и примеры: github.com/vidispine/hull .