Helm: чарт, релиз и первая установка

Kustomize накладывает правки на готовые манифесты. Helm идёт с другой стороны: манифесты в нём это шаблоны с подстановками, а конкретные значения подаются отдельно. Одна команда разворачивает всё приложение целиком.

Дальше речь про Helm 3. Это важно, потому что во второй версии в кластере жил серверный компонент Tiller с широкими правами, и половина старых статей описывает работу через него. В Helm 3 Tiller удалён: клиент общается с API-сервером напрямую, под теми же правами, что и ваш kubectl.

Чарт и релиз

Чарт - это пакет: папка с шаблонами манифестов, значениями по умолчанию и метаданными. Минимальный набор файлов внутри:

myapp/
  Chart.yaml       # имя, версия чарта, версия приложения
  values.yaml      # значения по умолчанию
  templates/       # шаблоны манифестов с подстановками
  charts/          # вложенные чарты-зависимости
  .helmignore

Релиз - это установленный экземпляр чарта в конкретном namespace. Один чарт ставится сколько угодно раз под разными именами релиза, и это будут независимые установки.

Откуда берут чарты

Обычный путь - репозиторий чартов:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm search repo nginx

Второй путь - локальная папка. Каркас чарта генерируется одной командой:

helm create myapp

helm create кладёт в папку myapp рабочий чарт по умолчанию: шаблоны Deployment, Service, ServiceAccount, Ingress и values.yaml с настройками. Сеть для этого не нужна, поэтому вариант удобен для разбора устройства чарта.

Установка релиза

helm install web ./myapp -n demo --create-namespace

web - это имя релиза, ./myapp - чарт, -n demo - namespace. Без --create-namespace Helm не станет создавать namespace сам и завершится ошибкой, если его нет.

Посмотреть, что получилось:

helm list -n demo
helm list -A
helm status web -n demo

Под капотом обычные объекты

Helm рендерит шаблоны в обычные манифесты и применяет их через тот же API. Никакой отдельной сущности в кластере у приложения не появляется, всё видно привычным kubectl:

kubectl get deploy,svc -n demo -l app.kubernetes.io/instance=web

Учёт релиза Helm ведёт сам. Состояние каждой ревизии он пишет в Secret в том же namespace, с именем вида sh.helm.release.v1.web.v1. Оттуда берутся история, откаты и ответ на вопрос, какие объекты принадлежат релизу.

Точный список применённых манифестов показывает:

helm get manifest web -n demo

Настройка через values

Шаблоны не трогают. Меняют значения, на которые эти шаблоны опираются. Флагом прямо в команде:

helm install web ./myapp -n demo \
  --set replicaCount=3 \
  --set image.repository=nginx \
  --set-string image.tag=1.25

Точка в --set означает вложенность: image.repository ляжет в image: {repository: ...}.

Посмотреть, какие значения вообще принимает чарт:

helm show values ./myapp

Проверить результат до установки:

helm template web ./myapp --set replicaCount=3
helm install web ./myapp -n demo --dry-run --debug

helm template рендерит локально и ничего не спрашивает у кластера. --dry-run отправляет запрос на API-сервер и потому ловит ещё и ошибки валидации.

Что обычно ломается

Имя релиза уникально внутри namespace. Повторный helm install web в тот же namespace даст ошибку про уже существующий релиз. В соседнем namespace то же имя займётся спокойно.

Забытый -n ставит релиз в namespace из текущего контекста kubectl, а не в тот, о котором вы думали. Потом helm list в другом namespace показывает пустоту, и кажется, что установка не прошла.

Запятая в --set разделяет пары значений, а точка означает вложенность. Если запятая или точка нужны внутри самого значения, их экранируют обратным слэшем: --set 'annotations.example\.com/id=a\,b'.

Ручная правка объектов, созданных Helm, через kubectl edit не отражается в состоянии релиза. Следующий helm upgrade соберёт манифесты из чарта и values и молча вернёт всё как было.

Домашка

Теорию закрепляет задание на своём кластере: 1 шаг с проверкой. Кластер поднимается по треку Kubernetes локально, задания лежат в репозитории k8s-practice.

./run.sh start k8s-helm-install     # развернуть стартовое состояние
./run.sh verify k8s-helm-install    # проверить текущий шаг

Коротко

• В Helm 3 нет Tiller: клиент работает с API-сервером под правами вашего kubeconfig.
• Чарт - это пакет шаблонов и значений, релиз - установленный экземпляр чарта в namespace.
• helm install <релиз> <чарт> -n <ns> ставит релиз; namespace создаётся только с --create-namespace.
• Helm применяет обычные Deployment и Service, а состояние релиза хранит в Secret sh.helm.release.v1.<релиз>.v<ревизия>.
• --set задаёт значения точечно, --set-string спасает числоподобные строки вроде тега образа.
• helm template и helm install --dry-run --debug показывают итоговые манифесты до установки.