Что такое Helm и Helm Charts: пакетный менеджер для Kubernetes простыми словами

Пока приложение маленькое, Kubernetes кажется терпимым: есть deployment.yaml, service.yaml, иногда ещё ingress.yaml. Но как только появляются dev, staging и production, один релиз быстро превращается в ручной перебор YAML-файлов, значений и копипаста между окружениями.

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

После Docker и Kubernetes вопрос обычно уже не в том, как запустить контейнер, а как не запутаться в конфигурации приложения целиком. Вот здесь и появляется Helm.

Что такое Helm и зачем он нужен

Helm — это утилита для установки и обновления приложений в Kubernetes. В официальной документации его прямо называют пакетным менеджером для Kubernetes. На практике это значит, что вы работаете не с россыпью YAML-файлов, а с одним chart-ом, в котором уже описаны нужные ресурсы и точки для подстановки значений.

Обычно Helm появляется в тот момент, когда в кластере у вас уже не один учебный Pod, а нормальное приложение: backend, PostgreSQL, ingress-nginx, Redis и ещё несколько настроек поверх. Держать такой набор манифестов вручную быстро становится тяжело, особенно если окружений несколько.

• убирает дублирование YAML между окружениями;
• позволяет параметризовать конфигурацию через values.yaml;
• устанавливает сложные приложения одной командой;
• хранит историю релизов и умеет откатывать неудачные обновления.

Если совсем коротко: Kubernetes запускает контейнеры, а Helm помогает ставить приложение в кластер как один цельный пакет.

Из чего состоит Helm: chart, release, repo и values.yaml

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

Что такое Helm Chart

Chart — это пакет приложения. В нём обычно лежат шаблоны Kubernetes-манифестов, файл Chart.yaml с метаданными, файл values.yaml со значениями по умолчанию и при необходимости зависимости от других chart-ов.

Что такое Helm Release

Release — это конкретная установленная копия chart-а в кластере. Один и тот же chart можно установить несколько раз с разными именами и настройками: например, myapp-dev и myapp-prod.

Что такое Chart Repository

Chart repository — это место, откуда вы забираете готовые chart-ы. Это может быть обычный HTTP-репозиторий с индексом пакетов или OCI-реестр. Для примеров в статье достаточно Bitnami.

Что такое values.yaml в Helm

values.yaml — файл со значениями для шаблонов. За счёт него один и тот же chart можно использовать в разных окружениях: рядом с базовым values.yaml появляются values-dev.yaml и values-prod.yaml, где меняются реплики, теги образов и домены.

			replicaCount: 2
image:
  repository: my-registry/myapp
  tag: "1.0.0"
service:
  type: ClusterIP
ingress:
  enabled: true
  host: app.example.com
		

Но сами values ещё не показывают, куда именно они подставятся. Ниже — минимальный фрагмент шаблона Deployment, который берёт значения из .Values.

			apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "myapp.fullname" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: app
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
		

А для разных окружений значения обычно раскладывают по отдельным файлам:

			# values-dev.yaml
replicaCount: 1
image:
  tag: "1.0.0-rc"
ingress:
  host: dev.example.com
---
# values-prod.yaml
replicaCount: 3
image:
  tag: "1.0.0"
ingress:
  host: app.example.com
		

Проще всего думать так: chart — это шаблон приложения, values — параметры для него, release — установленный экземпляр, repo — место, откуда этот шаблон взяли.

Как Helm работает на практике

Обычно сценарий очень приземлённый: подключили репозиторий с chart-ами, нашли нужный пакет, поставили его в кластер и при необходимости потом обновили или откатили.

			helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm search repo postgresql
helm install my-postgres bitnami/postgresql
		

После установки Helm создаёт release и раскладывает в кластер всё, что описано в chart-е. Если позже вы меняете, например, тег образа или число реплик в values-prod.yaml, релиз обновляется без ручной правки манифестов.

			helm upgrade my-postgres bitnami/postgresql -f values-prod.yaml
helm history my-postgres
helm rollback my-postgres 1
		

На практике вокруг helm upgrade и крутится большая часть работы: поменяли образ, значения или сам chart — обновили релиз. Если после этого что-то сломалось, helm rollback позволяет быстро вернуться к предыдущей версии.

Где здесь шаблоны

Внутри chart-а YAML почти всегда параметризован: количество реплик, тег образа, имена сервисов, домены. Поэтому один и тот же chart спокойно живёт и в dev, и в production.

Почему Helm — это не просто набор YAML-файлов

Голые манифесты в Git тоже работают. Проблемы начинаются позже: куски YAML дублируются, настройки между окружениями расползаются, а история конкретного релиза живёт у вас в голове. Helm хотя бы наводит в этом порядок.

Когда Helm удобнее kubectl apply, а когда нет

Helm не заменяет kubectl. kubectl работает с отдельными ресурсами, а Helm — с приложением как с пакетом.

• kubectl apply хорош, когда ресурсов мало и они почти не меняются.
• Helm удобнее, когда приложение состоит из многих манифестов и должно ставиться повторяемо.
• Kustomize часто выбирают, когда важнее патчи поверх базовых YAML, чем пакетная модель chart-ов.
• ArgoCD и другие GitOps-инструменты нередко используют Helm как источник шаблонов, а сами отвечают уже за непрерывную доставку.

Helm и ArgoCD обычно работают в связке. Helm отвечает за шаблоны и values, а ArgoCD следит, чтобы кластер действительно пришёл к состоянию из Git.

Если проводить грубую аналогию, то Docker пакует приложение, Kubernetes его запускает, а Helm приводит в порядок конфигурацию всего этого хозяйства.

Как начать работать с Helm: минимальный сценарий

Когда готовых chart-ов уже мало, следующий шаг — собрать свой. Команда helm create создаёт стартовый каркас: шаблоны, файл values.yaml и служебные метаданные.

			helm create myapp
tree myapp
		

Дальше всё довольно прозрачно: шаблоны лежат в templates/, значения — в values.yaml, а перед установкой вы можете заранее посмотреть, какой YAML Helm реально сгенерирует.

			helm template myapp ./myapp -f values.yaml
		

Это особенно удобно, когда нужно сравнить dev и production до деплоя: сначала смотрите итоговый YAML локально, потом уже делаете install или upgrade.

			helm template myapp ./myapp -f values-dev.yaml
		

Частые ошибки новичков в Helm

• Считать Helm заменой Kubernetes. На самом деле Helm только управляет шаблонами и релизами поверх Kubernetes API.
• Смешивать секреты, production values и тестовые настройки в одном файле. Лучше разделять values по окружениям.
• Запускать upgrade без понимания, что изменилось. Перед релизом полезно рендерить шаблоны через helm template.
• Игнорировать rollback-стратегию. История релизов — одна из самых практичных возможностей Helm, ей стоит пользоваться.
• Ставить Helm туда, где достаточно пары статичных манифестов. Если приложение маленькое, лишняя абстракция может только мешать.

На pet-проекте с двумя манифестами Helm и правда может быть лишним. Но как только появляются несколько сервисов, отдельные values для окружений и регулярные релизы, без него быстро становится тесно.

Выводы

Helm полезен не как модный инструмент из DevOps-стека, а как способ перестать руками таскать за собой растущий набор Kubernetes-манифестов.

Самый полезный следующий шаг после этой статьи — не читать ещё один ликбез, а собрать маленький учебный chart руками. Сгенерируйте его через helm create, вынесите настройки в values-dev.yaml и values-prod.yaml, прогоните helm template и сделайте первый install в Minikube или kind. После этого связка с CI/CD, Kubernetes и ArgoCD уже будет восприниматься намного проще.

Для старта хватит официальной инструкции по установке Helm, базового руководства и тестового кластера в Minikube или kind. Один вечер с install, template, upgrade и rollback обычно объясняет Helm лучше любого ликбеза.

Если хотите понять, где Helm находится в общей DevOps-цепочке, посмотрите план обучения DevOps-инженера. Там Helm связан с Docker, CI/CD, Kubernetes, наблюдаемостью и следующими шагами вроде GitOps и ArgoCD.