Что такое Helm: чарт, релиз, репозиторий

Три ключевых термина, без которых дальше не двинуться: chart, release и repository.

Helm — пакетный менеджер для Kubernetes. Если apt ставит пакеты в Linux, а npm — в Node-проект, то Helm ставит приложения в кластер Kubernetes.

Аналогия с пакетными менеджерами работает почти буквально, и она лучший способ запомнить термины. Давайте сопоставим.

Helm	Аналог в apt/npm	Что это
Chart	пакет (.deb / npm-пакет)	Шаблонизированное описание приложения для Kubernetes
Release	установленная программа	Конкретная установка чарта в кластер, с именем и ревизиями
Repository	apt-репозиторий / npm registry	Каталог, откуда скачиваются чарты
Values	конфиг при установке	Параметры, переопределяющие значения по умолчанию чарта

Chart — пакет приложения

Chart — это директория (или упакованный .tgz-архив) с шаблонами манифестов и метаданными. Внутри лежат заготовки Deployment, Service, ConfigMap с «дырками» под значения, файл значений по умолчанию и описание пакета. Чарт сам по себе ничего не запускает — это рецепт. По одному чарту можно сделать сколько угодно установок.

Важно: чарт версионируется. У чарта nginx может быть версия 15.4.2, и эта версия — самостоятельный артефакт, который можно зафиксировать, скачать, проверить и переустановить идентично через год.

У чарта на самом деле две независимые версии, и их легко спутать. Поле version — это версия самого чарта (рецепта): поменяли шаблон, добавили параметр — подняли её. Поле appVersion — это версия упакованного приложения (например, nginx 1.25.3). Они меняются по разным причинам: можно выпустить новую версию чарта, не трогая версию приложения (исправили опечатку в шаблоне), и наоборот, обновить приложение, оставив структуру чарта прежней. Когда вы фиксируете чарт в продакшене, фиксировать нужно именно version — она однозначно определяет, какой рецепт вы развернёте.

Полезная ментальная модель: чарт — это функция. На вход она принимает values, на выходе отдаёт набор манифестов Kubernetes. Как и у обычной функции, у неё есть значения аргументов по умолчанию (файл values.yaml внутри чарта), которые вызывающий может переопределить. Эта аналогия пригодится дальше: всё, что делает чарт «параметризуемым», — это аккуратно расставленные точки подстановки, через которые values протекают в финальный YAML.

Release — установленный экземпляр

Release рождается, когда вы выполняете helm install <имя> <чарт>. Один чарт можно установить много раз под разными именами — это будут разные релизы. Например, чарт postgresql можно поставить дважды: релиз orders-db и релиз billing-db, оба из одного чарта, но с разными значениями и в разных namespace.

# один чарт — два независимых релиза
helm install orders-db bitnami/postgresql
helm install billing-db bitnami/postgresql

helm list   # покажет оба релиза

У релиза есть ревизии: каждый helm upgrade создаёт новую ревизию (revision 2, 3, ...), а helm rollback возвращает на предыдущую. Helm хранит историю ревизий прямо в кластере (по умолчанию — в Secret в том же namespace).

Это решение — хранить состояние релиза в самом кластере, а не в локальном файле на машине инженера — принципиально для командной работы. Любой коллега с доступом к кластеру видит ту же историю релизов, что и вы: те же ревизии, те же применённые манифесты. Состояние не «у того, кто последним делал деплой», а общее. Заодно это объясняет, почему откат вообще возможен без доступа к исходным чартам: Helm сохраняет в Secret отрендеренные манифесты каждой ревизии целиком, поэтому helm rollback работает, даже если папку с чартом давно удалили.

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

Repository — каталог чартов

Repository — это HTTP-сервер с файлом index.yaml, который перечисляет доступные чарты и их версии, плюс сами .tgz-архивы. Вы добавляете репозиторий к себе один раз, а потом ищете и ставите из него чарты. Самый известный публичный источник — репозиторий Bitnami с готовыми чартами популярного софта.

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update            # обновить локальный индекс
helm search repo postgres   # найти чарты по слову

Современный Helm умеет тянуть чарты и из OCI-реестров (тех же, где живут Docker-образы) — об этом будет отдельный урок про публикацию.

Тут кроется источник частой путаницы. Когда вы делаете helm repo update, обновляется только локальный кеш индекса — список «какие версии чартов существуют в репозитории». Это не значит, что у вас обновятся уже установленные релизы: репозиторий и установленные релизы живут раздельно. Свежий индекс лишь даёт вам знать, что вышла, скажем, версия чарта 15.5.0; применить её к своему релизу — отдельное осознанное действие helm upgrade. Репозиторий поставляет рецепты, но никогда сам ничего не выкатывает в ваш кластер.

Values — четвёртая сущность, которая всё связывает

Хотя в названии урока три термина, без четвёртого — values — картина неполна. Именно values превращают один и тот же чарт в разные релизы. Чарт несёт значения по умолчанию, а при установке вы передаёте свой файл (или отдельные ключи через --set), и Helm накладывает ваши значения поверх дефолтных. Слияние идёт по ключам: вы переопределяете только то, что хотите изменить, а всё остальное берётся из чарта. Поэтому файл значений для конкретного окружения обычно компактный — пара десятков строк с тем, что отличает именно это окружение, а не полная копия конфигурации приложения.

Как это связано: жизненный путь

repository  --(helm install)-->  release  -->  поды в кластере
    |                                ^
   chart (шаблоны + values)         |
    +--- values переопределяют ------+

Поток такой: вы добавляете репозиторий, берёте из него чарт, подставляете свои values и выполняете install — получается релиз, который превращается в реальные объекты Kubernetes.

Частые ошибки в понимании

Путать chart и release. Chart — рецепт (статичный, версионируемый). Release — блюдо (конкретная установка). Один рецепт → много блюд.
Думать, что репозиторий обязателен. Чарт можно установить и из локальной папки: helm install web ./mychart. Репозиторий нужен лишь для распространения.
Считать, что имя релиза глобально. Имя релиза уникально в пределах namespace, а не всего кластера.

Итог

Chart — версионируемый пакет-рецепт приложения; Release — конкретная установка чарта; Repository — каталог, откуда чарты берутся.
Один чарт можно установить много раз как разные релизы.
У релиза есть ревизии и история, что и даёт откат.