Chart, Release и Values: три главных понятия

После первого знакомства с Helm важно не смешать всё в одно слово “chart”. Helm управляет не одним YAML-файлом, а связкой: пакет приложения, конкретная установка этого пакета и настройки, с которыми он установлен.

Helm становится понятным, когда разделить три сущности.

Понятие	Что означает
Chart	пакет с Kubernetes-манифестами и шаблонами
Release	конкретная установка chart'а в кластер
Values	настройки, которыми chart параметризуется

Один chart можно установить несколько раз с разными именами release:

helm install dev-web ./web-chart -f values-dev.yaml
helm install prod-web ./web-chart -f values-prod.yaml

Разбор helm install dev-web ./web-chart -f values-dev.yaml: install создаёт release, dev-web — имя release, ./web-chart — путь к chart, -f values-dev.yaml подмешивает файл values поверх defaults. Во второй строке тот же chart устанавливается как другой release с другими values.

Chart похож на рецепт. Release — приготовленное по рецепту блюдо в конкретной кухне. Values — параметры рецепта: размер порции, порт, image tag, включённые компоненты.

Технически это можно представить так:

Chart (шаблоны) + Values (настройки) + Release name/namespace
  -> render
  -> Kubernetes manifests
  -> объекты в кластере

Если изменить chart, меняется сам рецепт. Если изменить values, меняются параметры приготовления. Если сделать новый release, появляется отдельная установленная копия приложения со своей историей.

Важная идея: Chart, Release и Values нельзя смешивать в одну сущность.

Chart - это пакет, Values - настройки пакета, Release - установленный экземпляр в кластере. Когда Helm “ведёт себя странно”, почти всегда нужно понять, на каком из этих трёх уровней ошибка.

Chart

Chart - это директория или архив с описанием приложения. Минимальная структура:

mychart/
  Chart.yaml
  values.yaml
  templates/

Chart.yaml хранит metadata: имя, версию chart, версию приложения. values.yaml хранит значения по умолчанию. templates/ содержит Kubernetes-манифесты с Go template-вставками.

Chart можно хранить в Git, упаковать в .tgz, положить в Helm repository или использовать локально. Но в любом варианте chart сам по себе ещё ничего не запускает. Он становится реальными Kubernetes-объектами только после render и install/upgrade.

Важные версии:

Поле	Что означает
version	версия самого chart
appVersion	версия приложения внутри chart

Это разные вещи. Можно поменять шаблоны chart без смены image приложения, и можно поменять image tag без изменения структуры chart.

Release

Release - это установленный экземпляр chart в кластере. Команда:

helm install web ./mychart

создаёт release web. Проверка:

helm list
helm status web
helm get manifest web

helm list показывает releases в текущем namespace, helm status web показывает состояние конкретного release, helm get manifest web выводит Kubernetes YAML, который Helm применил для release web.

Удаление release:

helm uninstall web

После uninstall Kubernetes-ресурсы release обычно удаляются, но persistent data может остаться, если chart создавал PVC или внешние ресурсы.

Release важен потому, что Helm хранит его историю. Каждый helm upgrade создаёт новую revision. Благодаря этому можно посмотреть, какие значения применялись, какой manifest был сгенерирован и к какой revision откатиться.

helm history web
helm rollback web 2

Rollback не “возвращает время назад” в кластере. Он создаёт новую revision, где состояние снова соответствует старой revision. Это важно понимать при чтении истории.

Values

Values - это входные параметры для шаблонов:

replicaCount: 2
image:
  repository: nginx
  tag: alpine
service:
  type: ClusterIP

Переопределение:

helm install web ./mychart --set replicaCount=3
helm install web ./mychart -f custom-values.yaml

Практическое правило: сначала смотри values.yaml, затем делай override, затем проверяй helm template. Не угадывай путь вроде image.tag, если не видел структуру chart.

Values - это контракт между пользователем chart и автором chart. Если в values.yaml есть поле replicaCount, но template его нигде не использует, изменение поля ничего не даст. И наоборот: template может ожидать .Values.image.repository, а пользователь по ошибке задаёт .Values.imageRepo.

Поэтому правильный цикл такой:

helm show values ./chart
helm template web ./chart -f my-values.yaml
helm install web ./chart -f my-values.yaml

Сначала изучаем доступные настройки, потом смотрим итоговый YAML, и только затем применяем.

Что сравнивать после install

helm get values web
helm get values web --all
helm get manifest web
kubectl get deployment,svc

helm get values без --all показывает только пользовательские overrides, переданные через --set или -f. Значения из values.yaml внутри chart не считаются user-supplied values: это defaults chart'а. Поэтому release, установленный без override values, может показать USER-SUPPLIED VALUES: null.

helm get values web --all показывает итоговые значения вместе с defaults chart'а.

Namespace release

Release существует в namespace. Один и тот же release name можно использовать в разных namespace:

helm install web ./chart -n dev --create-namespace
helm install web ./chart -n prod --create-namespace
helm list -n dev
helm list -A

Здесь -n dev выбирает namespace dev, а --create-namespace создаёт его, если он ещё не существует. helm list -A смотрит releases во всех namespace, где у пользователя есть права.

Если helm status web ничего не находит, проверь namespace. Это частая ошибка в учебных и рабочих кластерах.

Как Helm хранит состояние

Helm 3 хранит информацию о release в Kubernetes Secret внутри namespace. Обычно руками их трогать не нужно, но полезно знать, почему helm history переживает перезапуск клиента:

kubectl get secret | grep sh.helm.release

Удаление этих Secret вручную ломает историю release. Управляй release через helm uninstall, helm upgrade, helm rollback.

Имена ресурсов в chart

Chart часто генерирует имена ресурсов из .Release.Name и .Chart.Name. Поэтому release web и release api из одного chart создадут разные Deployment/Service. Это позволяет ставить один chart несколько раз, но требует внимательно читать helm get manifest.

Как читать ошибку по уровням

Когда Helm-релиз не работает, полезно сразу разделить проблему на уровень Chart, Values или Release.

Chart  -> какие templates и defaults есть
Values -> какие настройки передали
Release -> что установлено в конкретном namespace и какая revision активна

Примеры:

Симптом	Вероятный уровень
helm template падает с template-ошибкой	Chart
override не изменил image	Values или template не использует это поле
helm status не находит release	Release name или namespace
Pod не стартует после успешного install	Kubernetes-объекты, сгенерированные release
rollback не вернул данные	данные были в PVC или внешней системе, не только в release

Такой разбор защищает от хаотичной отладки. Например, если helm template уже показывает неправильный Service port, проблема ещё до Kubernetes. Если render правильный, но Pod не Ready, переходи к kubectl describe и kubectl logs.

Типичные ошибки

Симптом	Частая причина
helm status web не находит release	выбран не тот namespace
override не изменил manifest	неверный путь в values или template не использует поле
два release конфликтуют	chart генерирует одинаковые имена ресурсов
после uninstall остались данные	PVC или внешние ресурсы не удаляются вместе с release
helm list пустой	release в другом namespace, проверь helm list -A

Если держать отдельно Chart, Release и Values, большинство ошибок становится проще разобрать: либо не тот пакет, либо не те настройки, либо не тот установленный экземпляр.

Практическое правило для лабораторных

Перед каждой Helm-командой проговаривай три вещи:

release name: web
chart: ./web-chart
values: values-dev.yaml + --set image.tag=...

После команды проверь:

helm status web
helm get values web --all
helm get manifest web

Так ты видишь не только факт установки, но и связь между входными values и итоговым Kubernetes YAML.