Пока у приложения один Deployment и Service, Helm не нужен. Но когда окружения отличаются тегом образа и парой параметров, поддерживать YAML-файлы вручную становится тяжело. Helm упаковывает манифесты в чарт, подставляет values и хранит историю релизов, поэтому откат занимает одну команду. В 2026 году актуален Helm 4 с server-side apply, а поддержка Helm 3 завершается в феврале 2027 года. Разберём цикл от установки до публикации в OCI.

Что такое чарт и релиз

Чарт — это каталог с шаблонами Go template, файлом метаданных Chart.yaml и значениями по умолчанию values.yaml. Шаблоны превращаются в обычные манифесты Kubernetes, поэтому Helm не требует агента в кластере. Релиз — конкретный экземпляр чарта в namespace. Сведения о релизах хранятся в Secret этого namespace, поэтому права на namespace — это права на релизы, а перенос чарта в другой кластер — новая установка, а не копирование истории.

Helm не заменяет GitOps и не управляет состоянием приложения: он удобен для параметризации и повторяемой установки. Для одного пода проще kubectl apply, для набора ресурсов — чарт.

Установка и проверка

Helm есть в репозиториях многих дистрибутивов, но версия может отставать. Для свежей ветки 4 скачайте архив с официального GitHub Releases, сверьте контрольную сумму и распакуйте бинарник в /usr/local/bin. Установочные скрипты не запускайте вслепую: прочитайте.

helm version
helm env
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm version показывает клиентскую и серверную часть, если настроен доступ к кластеру; helm env печатает пути к конфигурации и репозиториям. Репозиторий — это индекс index.yaml с архивами чартов; repo update обновляет индекс, а чарты скачиваются при установке.

Структура чарта

helm create myapp
find myapp -maxdepth 2 -type f | sort
helm lint myapp

helm create создаёт каркас: Chart.yaml, values.yaml, каталог templates с Deployment, Service, Ingress и помощниками _helpers.tpl, а также templates/tests. Файлы в templates — шаблоны: {{ .Values.image.repository }} подставляет значение, а {{ include "myapp.fullname" . }} вызывает общий помощник. helm lint проверяет синтаксис и типичные ошибки, но не заменяет проверку в кластере.

Values и рендеринг без установки

helm template myapp ./myapp -n demo --set image.tag=1.2.3
helm template myapp ./myapp -n demo -f values-prod.yaml --debug

helm template показывает итоговые манифесты и ничего не отправляет в кластер — быстрый способ поймать ошибку. Приоритет значений: values.yaml чарта, затем файлы -f в порядке указания, затем --set. Для строк, похожих на числа, используйте --set-string, иначе 1.20 превратится в 1.2.

Установка и обновление

helm install myapp ./myapp -n demo --create-namespace --wait --timeout 5m
helm list -n demo
helm status myapp -n demo
helm upgrade --install myapp ./myapp -n demo -f values-prod.yaml --wait

--wait ждёт готовности ресурсов и полезен в CI, но при ошибке установка останется в failed. --rollback-on-failure автоматически откатывает релиз; старый --atomic оставлен синонимом. Связка helm upgrade --install идемпотентна: установит чарт или обновит существующий. Перед обновлением сохраните значения: helm get values myapp -n demo --all > values-backup.yaml.

История и откат

helm history myapp -n demo
helm rollback myapp 2 -n demo --wait
helm get manifest myapp -n demo
helm uninstall myapp -n demo --keep-history

Каждое изменение создаёт ревизию. helm history показывает номера, статус и описание, а rollback возвращает манифесты выбранной ревизии и добавляет новую запись — исходные данные не перезаписываются. helm get manifest помогает сравнить отправленные ресурсы с шаблоном. --keep-history сохраняет историю при удалении, но такой релиз нельзя обновить без повторной установки.

Helm 4 и server-side apply

Главное изменение Helm 4 — server-side apply (SSA). При новой установке поля объединяет API-сервер, а Helm записывает владельца. Обновление и откат используют --server-side=auto: режим наследуется от предыдущей ревизии. Поэтому релиз из Helm 3 останется на client-side apply, пока вы явно не включите SSA. При конфликте Helm называет поле и менеджера — например, HPA с spec.replicas.

helm upgrade myapp ./myapp -n demo --server-side=true
kubectl get deployment myapp -n demo --show-managed-fields -o yaml
helm upgrade myapp ./myapp -n demo --server-side=true --force-conflicts

--force-conflicts забирает владение полем, но может перетереть изменение оператора. В Helm 4 --force переименован в --force-replace, а --atomic — в --rollback-on-failure; старые имена работают, но в скриптах лучше использовать новые. Проверяйте чарты в тестовом кластере: helm template не покажет конфликты применения.

Плагины и OCI-реестр

helm plugin install https://github.com/databus23/helm-diff
helm diff upgrade myapp ./myapp -n demo -f values-prod.yaml
helm package ./myapp
helm push myapp-0.1.0.tgz oci://registry.example.com/charts

Плагин helm-diff показывает, что изменится при обновлении, и ловит неожиданные правки Service или аннотаций. Для публикации в OCI нужен helm registry login registry.example.com; установка потом выглядит так: helm install myapp oci://registry.example.com/charts/myapp --version 0.1.0 -n demo. Имя архива собирается из имени чарта и version в Chart.yaml, поэтому проверьте её перед сборкой.

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

  • Ресурс уже существует. Чарт создаёт объект, которым управляет другой релиз. Проверьте аннотации meta.helm.sh/release-name, а в Helm 4 используйте --take-ownership.
  • Схема values не проходит. В чарте есть values.schema.json; сообщение указывает поле и тип. Приведите YAML к схеме, а не отключайте проверку.
  • --wait зависает. Смотрите kubectl describe и события пода: часто дело в образе, секрете или квоте.
  • Операция уже выполняется. Релиз остался в pending-install. Проверьте helm history и helm status, дождитесь завершения или откатитесь.
  • CRD не обновились. Каталог crds/ применяется при установке и не шаблонизируется; обновляйте CRD отдельным шагом.

Чек-лист перед выкладкой

  1. helm lint и helm template с рабочими values проходят.
  2. Тег образа зафиксирован, а не равен latest.
  3. helm diff upgrade показывает только ожидаемые изменения.
  4. Есть план отката: номер ревизии и резервная копия values.
  5. После обновления проверены Pods, Service и логи, а не только код.

Итог

Helm остаётся удобным слоем между шаблонами и кластером: чарт описывает приложение один раз, values задают различия сред, а история релизов даёт быстрый откат. В 2026 году планируйте переход на Helm 4 и проверяйте чарты с server-side apply, не дожидаясь окончания поддержки третьей ветки. Начните с helm template и helm diff, а --force-conflicts применяйте осознанно.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Поделиться: Telegram ВКонтакте