Что такое Helm и как он работает в Kubernetes

Helm — пакетный менеджер для Kubernetes. Он упаковывает файлы приложения в настраиваемый пакет и разворачивает его в кластере одной командой. По принципу работы это похоже на apt в Ubuntu или npm в Node.js: вы запускаете установку, а инструмент подтягивает и обновляет все нужные зависимости. Разница в том, что вместо программ на одной машине Helm управляет развёртыванием целого приложения внутри Kubernetes‑кластера.

В этой статье мы разберём, что такое Helm, зачем он нужен, какие возможности даёт и как устроен. Затем на примере покажем, как с его помощью разворачивать приложение, обсудим альтернативы и подскажем, с чего начать знакомство.

Объяснять материал мы будем простыми словами, но тема не рассчитана на новичков. Чтобы понять примеры и команды, вы должны хотя бы немного ориентироваться в Kubernetes. Нужно знать, как устроен кластер и из чего он состоит, что такое контейнеры и образы Docker, а также основные объекты Kubernetes: Deployment, Service, ConfigMap, Secret, Ingress. Ещё нужно понимать, что такое YAML-манифесты и как выполняются команды kubectl.

Содержание

• Для чего нужен Helm
• Возможности Helm
• Архитектура Helm
• Как работает Helm
• Чем заменить Helm и что почитать по теме

Для чего нужен Helm

Проще всего оценить пользу Helm, если представить работу без него. Даже у простого веб-сервиса в Kubernetes обычно есть несколько объектов: Deployment запускает нужное число копий приложения, Service открывает к ним доступ, ConfigMap хранит конфигурацию, Secret — пароли и токены, а Ingress пропускает входящий HTTP- и HTTPS-трафик. Каждый объект описывается отдельным YAML-манифестом, и всё это нужно применять вручную: выполнить несколько команд kubectl apply, соблюдать порядок и не забыть ни один файл.

Получается, что при ручном развёртывании такого сервиса необходимо сделать много однотипной работы: подготовить 5-6 YAML‑файлов (Deployment, Service, ConfigMap, Secret, Ingress и так далее), затем применить их по очереди командами kubectl apply. А когда нужно развернуть этот же сервис во втором окружении (например, в stage вместо dev), практически всё приходится повторять заново: копировать те же манифесты, менять в них значения (адреса, пароли, лимиты ресурсов, число реплик) и обязательно следить за тем, чтобы в кластере была именно та версия конфигурации, которую вы ожидаете.

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

• Упаковка приложения в пакет. Манифесты сервиса объединяют в чарт (chart) — то есть «пакет» в терминологии Helm: набор YAML‑шаблонов, значений по умолчанию и метаданных. Затем с этим чартом работают как с единым артефактом: устанавливают, обновляют и удаляют его командами Helm, вместо того чтобы применять каждый манифест по отдельности.
• Параметризация под окружения. Настройки чарта выносят в отдельный файл, а в шаблонах используют подстановки. Благодаря этому один и тот же чарт можно разворачивать в dev, stage и prod, подставляя разные значения — например, через helm install -f values-prod.yaml. Копировать манифесты и вручную править их не нужно — достаточно поменять файл со значениями.
• Быстрая установка, обновление и откат релизов. Установленный в кластере чарт называют релизом (release). Каждое действие с ним — helm install, затем helm upgrade — Helm сохраняет как отдельную ревизию с номером. Благодаря этой истории откат делается одной командой: helm rollback вернёт релиз к предыдущей версии, если обновление пошло не так.
• Готовые решения вместо написания с нуля. Многие популярные приложения уже упакованы в чарты и выложены в репозитории чартов — открытые хранилища, откуда их можно устанавливать. Всё просто: добавляете репозиторий командой helm repo add, а затем устанавливаете нужный чарт через helm install — Helm сам скачает его и развернёт в кластере. Так часто поднимают, например, базу данных PostgreSQL, систему мониторинга Prometheus, панели Grafana — всё это готовые чарты, которые сообщество уже собрало, так что писать манифесты самому не придётся.

Готовые чарты удобно искать в Artifact Hub — официальном каталоге пакетов для Kubernetes. Там указаны версия чарта, число загрузок и команда установки, поэтому ту же Prometheus можно добавить, не разбираясь в её манифестах.

Возможности Helm

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

Манифесты в чарте — это не готовые файлы с жёстко прописанными значениями, а шаблоны, как бланк с пропусками. Вместо конкретного числа или адреса в них стоит метка вроде replicaCount, а сами значения хранятся отдельно — в файле values.yaml. При установке Helm берёт шаблон, подставляет в пропуски нужные значения и получает обычные манифесты для Kubernetes. Например, для тестовой среды можно задать replicaCount: 1, а для продакшена — replicaCount: 5: шаблон не меняется, меняется только файл со значениями.

Все остальные возможности развивают идею шаблонов и делают Helm полноценным пакетным менеджером для Kubernetes. Давайте их перечислим:

• Управление зависимостями. Helm помогает собирать приложение из нескольких чартов. Например, у вас есть чарт my-app, и вы хотите разворачивать его вместе с базой PostgreSQL. Достаточно указать PostgreSQL как зависимость в Chart.yaml — дальше Helm сам скачает нужный чарт из репозитория и установит его вместе с приложением. Вам не придётся отдельно устанавливать базу и проверять совместимость версий.
• Хуки жизненного цикла. Helm может выполнять дополнительные действия в ключевые моменты жизненного цикла релиза — при установке, обновлении или удалении приложения из кластера. Эти действия называют хуками, и по их названиям обычно понятно, до или после какого этапа они запускаются: pre-install, post-upgrade, pre-delete и другие. Хуки помогают автоматизировать сопутствующие задачи — например, создание ресурсов перед установкой, запуск миграций базы данных перед обновлением, резервное копирование перед откатом или очистку ресурсов после удаления.
• Хранение чартов в OCI-репозиториях. Чарты можно упаковать и хранить в обычном контейнерном реестре — там же, где находятся Docker-образы. Это возможно благодаря стандарту OCI (Open Container Initiative), который определяет формат таких реестров. В результате чарты и образы оказываются в одном месте, с привычными правами доступа, и нет необходимости поднимать отдельную инфраструктуру для хранения чартов.

Лучше всего эти возможности видны на практике. Допустим, вы выкатываете веб‑приложение, которому нужна база данных. Базу не придётся описывать с нуля: подключаете её как зависимость чарта — и Helm сразу поднимает оба компонента. А чтобы при каждом обновлении автоматически прогонять миграции схемы, добавляете хук pre-upgrade: он запустит разовую задачу перед выпуском новой версии. Так установка, зависимости и сервисные операции остаются в одном пакете, а не разбросаны по скриптам и инструкциям.

Архитектура Helm

В основе Helm — клиентская утилита, которая работает на вашем компьютере. Она собирает из чарта манифесты, передаёт их в Kubernetes, а сведения об установленных релизах сохраняет прямо в кластере. Давайте кратко разберём, как всё это устроено, из чего состоит чарт и что изменилось с выходом Helm 4.

Клиентская архитектура без Tiller. В Helm 2 с кластером взаимодействовал серверный компонент Tiller, который нередко имел доступ ко всем namespace — отдельным областям кластера с разными приложениями и средами. Эти права могли быть шире, чем у самого пользователя. Поэтому в третьей версии Tiller убрали, и теперь Helm учитывает права пользователя и не позволяет разработчику с доступом только к тестовой среде изменить продакшен.

Разработчик
    ↓
Helm CLI
    │
    │ Рендерит чарт и отправляет манифесты
    │ Подключается с учётными данными из kubeconfig
    │ Действия ограничиваются правилами RBAC
    ↓
Kubernetes API-сервер
    ├── Объекты приложения
    │    Deployment, Service, ConfigMap
    │
    └── Ревизии релиза
         Secrets в namespace

Чарт. Мы уже говорили, что чарт — это пакет, в котором описано приложение для Kubernetes. Однако если посмотреть на чарт с точки зрения структуры, это лишь папка со стандартным набором файлов и подпапок. Helm умеет создать такую заготовку командой helm create, а дальше вам останется адаптировать её под конкретное приложение. Перечислим основные элементы чарта:

• Chart.yaml — метаданные чарта: название, версия, описание и зависимости;
• values.yaml — значения, которые по умолчанию подставляются в шаблоны;
• templates/ — шаблоны манифестов, например Deployment и Service;
• templates/_helpers.tpl — общие фрагменты шаблонов, которые помогают не повторять один и тот же код;
• templates/NOTES.txt — подсказка, которую Helm выводит после установки приложения;
• charts/ — вложенные чарты-зависимости;
• crds/ — описания пользовательских типов ресурсов (CRD);
• .helmignore — файлы, которые не нужно включать в готовый пакет.

К примеру, простой чарт mychart может быть устроен так:

mychart/
├── Chart.yaml
├── values.yaml
├── .helmignore
├── charts/
├── crds/
└── templates/
    ├── deployment.yaml
    ├── service.yaml
    ├── _helpers.tpl
    └── NOTES.txt

Стандартная структура упрощает поиск настроек и шаблонов. При установке значения из values.yaml можно переопределить через -f my-values.yaml или --set replicaCount=3. Самый высокий приоритет у параметров командной строки, затем идёт файл со значениями, после — дефолтные значения. Поэтому один и тот же чарт подходит для разных окружений без правок в файлах.

Хранилище релизов. После установки Helm сохраняет сведения о релизе прямо в Kubernetes — по умолчанию в объектах Secret в том же namespace, где развёрнуто приложение. В этих Secret хранится всё, что нужно для восстановления релиза: конфигурация чарта, сгенерированные манифесты и служебная информация. Поэтому отдельная база данных Helm не нужна.

При установке и каждом обновлении Helm создаёт новый Secret с данными релиза и номером ревизии. Например, вы установили релиз myapp, а потом один раз сделали helm upgrade — тогда в namespace появятся две записи:

$ kubectl get secret -l owner=helm
NAME                              TYPE                 DATA   AGE
sh.helm.release.v1.myapp.v1       helm.sh/release.v1   1      10m
sh.helm.release.v1.myapp.v2       helm.sh/release.v1   1      2m

В этом примере записи v1 и v2 — это две сохранённые версии релиза: первая появилась после установки, вторая — после обновления. Если обновление нарушило работу приложения, можно выполнить helm rollback myapp 1. Helm найдёт данные первой версии и восстановит прежнее состояние приложения.

Изменения в Helm 4. В ноябре 2025 года вышел Helm 4 — первый мажорный релиз за шесть лет. Общая архитектура при этом не изменилась: клиент по‑прежнему обращается к Kubernetes API‑серверу, а данные о релизах хранит в кластере. Обновились механизмы, которые используются внутри этой схемы.

Например, Helm получил поддержку server-side apply: теперь Kubernetes сам объединяет изменения в ресурсах и учитывает, какой инструмент управляет отдельными полями. Это снижает риск конфликтов, если один Deployment изменяют и через Helm, и другими способами. Кроме того, Helm точнее определяет готовность ресурсов после установки или обновления, а плагины теперь можно создавать на WebAssembly и запускать в изолированной среде.

Читайте также:

Всё о WebAssembly: зачем он нужен, кто на нём пишет, как он устроен и кто его делает

Как работает Helm

Когда вы запускаете helm install, Helm читает чарт, подставляет значения из values.yaml в шаблоны, формирует обычные Kubernetes‑манифесты и отправляет их в API‑сервер. Затем он сохраняет информацию о релизе в кластере. Дальше работает Kubernetes: создаёт Deployment, запускает поды, настраивает Service и другие объекты. Сам Helm контейнеры не запускает.

Схематически процесс выглядит так:

Чарт и значения
        ↓
Helm создаёт готовые манифесты
        ↓
Kubernetes API-сервер
        ├── создаёт объекты приложения
        └── сохраняет сведения о релизе

Далее мы рассмотрим работу Helm на простом примере. Если вы захотите повторить все действия самостоятельно, подготовьте следующее:

• компьютер с установленными Helm и утилитой kubectl;
• запущенный тестовый Kubernetes-кластер — например, локальный Minikube, Kind или любой учебный кластер;
• настроенный доступ к кластеру через kubectl и права на создание ресурсов.

Затем откройте терминал и проверьте подключение командой kubectl cluster-info. Убедитесь, что вы подключены к тестовому кластеру, а не к production. После этого, не закрывая терминал, создайте заготовку чарта:

helm create web

В каталоге web появятся файлы Chart.yaml, values.yaml и набор шаблонов. Во время установки Helm подставит в них значения и сгенерирует манифесты Kubernetes. Чтобы посмотреть результат, не обращаясь к кластеру, выполните:

helm template web ./web

Если всё отрендерилось без ошибок, давайте установим чарт:

helm install web ./web

Первое web — это имя релиза, а ./web — путь к чарту. Helm применит ресурсы в Kubernetes и сохранит первую ревизию. Проверить релиз вы можете командой helm list. Теперь давайте увеличим число реплик приложения до трёх:

helm upgrade web ./web --set replicaCount=3

Обновление создаст новую ревизию, а предыдущая останется в истории. Посмотреть их можно командой helm history web. А если вдруг новая конфигурация работает неправильно, выполните откат к первой ревизии:

helm rollback web 1

Так Helm собирает из шаблонов готовые ресурсы Kubernetes и позволяет управлять ими как единым релизом: устанавливать, обновлять и откатывать.

Держите шпаргалку по основным командам:

• helm create <имя> — создаёт заготовку чарта;
• helm template <релиз> <чарт> — генерирует манифесты;
• helm install <релиз> <чарт> — устанавливает новый релиз;
• helm upgrade <релиз> <чарт> — обновляет релиз;
• helm list — показывает установленные релизы;
• helm history <релиз> — показывает историю ревизий;
• helm rollback <релиз> <ревизия> — возвращает выбранную ревизию;
• helm uninstall <релиз> — удаляет релиз из кластера.

Чем заменить Helm и что почитать по теме

Helm удобнее всего осваивать на практике: установите его, разверните пробный чарт в тестовом кластере, а затем изучите несколько готовых пакетов. Разобраться с командами и устройством чартов помогут следующие источники:

• Начните с официальной документации. В ней подробно описаны процесс установки и список всех команд. Также доступен русскоязычный раздел.
• Изучите готовые чарты в Artifact Hub. Их можно устанавливать в тестовом кластере и разбирать, какие Kubernetes‑ресурсы они создают.
• Следите за развитием Helm на GitHub. В репозитории вы найдёте исходный код, новые релизы, списки изменений и обсуждения задач.
• Обращайтесь к сообществу, если нужна помощь. Полезные материалы и обсуждения есть в телеграм-каналах «Флант», «Kubernetes и кот Лихачёва» и k8s (in)security, а также в канале #helm-users в Slack Kubernetes.

При всех своих преимуществах Helm подходит не для каждой задачи. По мере роста чарта шаблоны и файлы значений могут усложняться, из-за чего конфигурацию становится труднее читать и отлаживать. Если вам не нужны упаковка приложения, репозитории чартов и история релизов, можно выбрать более простой подход. Главная альтернатива — Kustomize, встроенный в kubectl.

В отличие от Helm, Kustomize не делает из манифестов шаблоны. Он берёт базовый набор YAML‑файлов и поверх него накладывает изменения для разных окружений. Поэтому Kustomize удобнее для поддержки и настройки своих манифестов, а Helm — для упаковки, установки и обновления приложений.