Helm — это пакетный менеджер для Kubernetes, который упрощает установку, настройку, обновление и удаление приложений в кластере. Вместо ручного управления большим количеством YAML-манифестов Helm позволяет объединять связанные Kubernetes-ресурсы в единый пакет, который называется Chart.
Helm особенно полезен для приложений, состоящих из нескольких объектов Kubernetes: Deployment, Service, ConfigMap, Secret, Ingress и других ресурсов. Все они могут быть описаны внутри одного Chart и развернуты одной командой.
Например, чтобы установить веб-приложение вручную, администратору может потребоваться применить десять YAML-файлов. С Helm эти файлы объединяются в пакет, параметры выносятся в отдельную конфигурацию, а установка выполняется как единая операция.
Что такое Helm простыми словами
Helm можно сравнить с пакетным менеджером операционной системы, но для Kubernetes.
В Linux пакетный менеджер позволяет установить приложение вместе с необходимыми файлами и зависимостями. Helm решает похожую задачу на уровне Kubernetes: он хранит описание ресурсов приложения и помогает развернуть их в кластер.
Главная идея Helm — превратить набор Kubernetes-манифестов в переиспользуемый, параметризуемый и версионируемый пакет.
Это особенно удобно, если одно приложение нужно устанавливать несколько раз: например, в development, staging и production.
Для чего нужен Helm
Без Helm команда может хранить десятки почти одинаковых YAML-файлов для разных окружений. Со временем они начинают расходиться, а каждое изменение приходится дублировать вручную.
Helm позволяет использовать один набор шаблонов и передавать разные параметры для каждого окружения.
- установка приложений в Kubernetes;
- управление большим количеством YAML-манифестов;
- параметризация конфигурации;
- повторное использование шаблонов;
- обновление приложений;
- откат релизов;
- хранение версий пакетов;
- разделение конфигураций development и production;
- автоматизация развертывания через CI/CD;
- распространение готовых Kubernetes-приложений.
Что такое Helm Chart
Chart — пакет Helm, содержащий описание Kubernetes-приложения.
Внутри Chart находятся шаблоны Kubernetes-ресурсов, метаданные пакета и значения параметров по умолчанию.
Например, Chart веб-приложения может содержать шаблоны Deployment, Service, Ingress и ConfigMap.
При установке Helm подставляет необходимые значения в шаблоны и формирует обычные Kubernetes-манифесты, которые затем применяются к кластеру.
Структура Helm Chart
Типичный Chart содержит несколько основных элементов.
| Элемент | Назначение |
|---|---|
| Chart.yaml | Метаданные Chart: имя, версия и другая информация |
| values.yaml | Значения параметров по умолчанию |
| templates | Шаблоны Kubernetes-манифестов |
| charts | Зависимые Charts |
Дополнительно в проекте могут присутствовать вспомогательные файлы, документация и тестовые шаблоны.
Что такое values.yaml
values.yaml содержит параметры, которые используются при генерации Kubernetes-манифестов.
Например, в нем можно указать количество реплик, имя Docker-образа, порт приложения или лимиты ресурсов.
replicaCount: 3 image: repository: example/app tag: stable service: port: 80
Шаблоны Helm обращаются к этим значениям и подставляют их в соответствующие места.
Зачем нужны Values
Values позволяют использовать один Chart для разных окружений.
Например, в development можно запускать одну реплику приложения с небольшим количеством ресурсов, а в production — пять реплик и более высокие лимиты CPU и памяти.
При этом сами шаблоны остаются одинаковыми. Меняются только значения.
| Параметр | Development | Production |
|---|---|---|
| Реплики | 1 | 5 |
| CPU | Небольшой лимит | Повышенный лимит |
| Домен | dev.example.ru | example.ru |
| Автомасштабирование | Может быть отключено | Может быть включено |
Что такое Helm Template
Templates — Kubernetes-манифесты с динамическими выражениями.
Например, обычный Deployment содержит фиксированное количество реплик. В Helm вместо числа можно указать переменную, которая берется из values.yaml.
replicas: {{ .Values.replicaCount }}Во время установки Helm заменяет выражение реальным значением и создает итоговый YAML.
Шаблоны позволяют добавлять условия, циклы и другую логику, но чрезмерно сложные шаблоны могут сделать Chart трудным для сопровождения.
Что такое Release в Helm
Release — конкретная установленная версия Chart в Kubernetes-кластере.
Один и тот же Chart можно установить несколько раз с разными именами и параметрами.
Например, Chart корпоративного приложения можно установить как test-app и production-app.
Каждая установка считается отдельным release и имеет собственную историю изменений.
Chart и Release — в чем разница
| Chart | Release |
|---|---|
| Шаблон приложения | Конкретная установка этого шаблона |
| Можно использовать многократно | Связан с определенным кластером и настройками |
| Содержит templates и values | Имеет собственную историю версий |
Chart можно сравнить с чертежом, а Release — с конкретным объектом, созданным по этому чертежу.
Как работает установка Helm
При установке происходят несколько основных действий.
- Helm загружает Chart.
- Читает values по умолчанию.
- Добавляет значения, переданные пользователем.
- Обрабатывает templates.
- Формирует итоговые Kubernetes-манифесты.
- Передает их Kubernetes API.
- Сохраняет информацию о release.
После этого Kubernetes уже самостоятельно создает pod, Service, Deployment и другие объекты.
Helm не заменяет Kubernetes
Helm не запускает контейнеры самостоятельно и не является альтернативой Kubernetes.
Он только упрощает управление манифестами и взаимодействует с Kubernetes API.
После установки именно Kubernetes контролирует состояние pod, перезапускает контейнеры и выполняет другие функции оркестрации.
Helm и kubectl
kubectl — основной инструмент командной строки для прямой работы с Kubernetes API. Helm располагается уровнем выше и управляет группой связанных ресурсов как одним приложением.
| kubectl | Helm |
|---|---|
| Применяет Kubernetes-манифесты | Генерирует и устанавливает набор манифестов |
| Работает с отдельными ресурсами | Работает с приложением как с release |
| Не предоставляет модель Chart | Использует Charts и Values |
| Подходит для прямого администрирования | Удобен для повторяемых установок |
На практике команды используют оба инструмента.
Helm Repository
Helm Repository — хранилище Charts, из которого их можно загружать и устанавливать.
Компания может использовать публичные репозитории или создать внутреннее хранилище собственных пакетов.
Это позволяет командам распространять стандартные приложения без копирования исходных YAML-файлов между проектами.
Зачем нужны репозитории Charts
Представим организацию с десятками команд. Каждой требуется стандартный набор мониторинга или типовой веб-сервис.
Инфраструктурная команда создает проверенный Chart и публикует его во внутреннем репозитории.
Другие команды устанавливают приложение как готовый пакет и меняют только разрешенные параметры.
Это помогает стандартизировать инфраструктуру и уменьшить дублирование.
Версия Chart
Chart имеет собственную версию. Она отражает изменение самого пакета: шаблонов, values или структуры.
Версионирование позволяет понимать, какая конфигурация используется в конкретном окружении.
Например, production может работать на одной версии Chart, а test уже проверять следующую.
Это также упрощает откаты и контролируемое обновление приложений.
Версия Chart и версия приложения
Версия Helm Chart и версия самого приложения — разные понятия.
Chart может измениться из-за нового параметра Kubernetes, даже если Docker-образ приложения остался прежним.
И наоборот, можно выпустить новую версию приложения и использовать тот же общий шаблон развертывания.
Поэтому эти версии желательно учитывать отдельно.
Обновление через Helm
Если конфигурация или версия приложения изменились, Helm может обновить существующий release.
Например, команда меняет Docker-образ с версии 1.0 на 1.1 и запускает обновление.
Helm формирует новые манифесты и передает изменения Kubernetes.
Дальнейшее поведение зависит от Kubernetes-ресурсов и настроенной стратегии обновления.
Что такое Rollback
Helm сохраняет историю release, поэтому можно вернуться к предыдущей ревизии.
Например, после обновления приложения пользователи начинают получать ошибки. Если проблема связана с новой конфигурацией, команда может выполнить rollback.
Helm восстановит предыдущую версию описания ресурсов.
Однако rollback не всегда автоматически восстанавливает состояние данных, поэтому изменения баз данных требуют отдельного планирования.
Что такое Revision
Каждое обновление release создает новую ревизию.
Первая установка имеет одну ревизию, последующее обновление — следующую.
История позволяет увидеть последовательность изменений и выбрать версию для отката.
Helm и CI/CD
Helm широко используется в CI/CD для автоматизированного развертывания приложений в Kubernetes.
Например, pipeline собирает Docker-образ, запускает тесты, публикует образ в Registry и затем обновляет Helm release.
При этом версия образа может передаваться в Chart как параметр.
Таким образом, процесс от изменения кода до обновления приложения в Kubernetes становится автоматизированным.
Helm и DevOps
Helm является распространенным инструментом DevOps, поскольку помогает стандартизировать Kubernetes-развертывания.
Разработчики получают типовые шаблоны, а инфраструктурная команда может контролировать обязательные настройки: ресурсы, probes, labels, политики и другие параметры.
Это уменьшает количество различий между приложениями.
Helm и Infrastructure as Code
Helm близок к Infrastructure as Code, поскольку Kubernetes-ресурсы описываются декларативно и хранятся как код.
Однако Terraform и Helm обычно работают на разных уровнях.
Terraform часто создает инфраструктуру: сеть, Kubernetes-кластер, балансировщики и облачные ресурсы. Helm затем устанавливает приложения внутрь уже созданного кластера.
| Terraform | Helm |
|---|---|
| Создает инфраструктурные ресурсы | Устанавливает Kubernetes-приложения |
| Управляет сетями и кластерами | Управляет Charts и Releases |
| Использует providers | Использует templates и values |
Helm и Terraform вместе
На практике Terraform и Helm часто дополняют друг друга.
Например, Terraform создает облачную сеть и Kubernetes-кластер. После этого Helm устанавливает Prometheus, Grafana, Ingress Controller и бизнес-приложения.
Так инфраструктурный и прикладной уровни остаются разделенными, но могут управляться через единый автоматизированный процесс.
Helm и Kubernetes
Helm работает поверх стандартной модели Kubernetes.
Все созданные им объекты остаются обычными Kubernetes-ресурсами. Их можно просматривать через kubectl и стандартные API.
Это важно: Helm не создает отдельную скрытую инфраструктуру, а управляет набором обычных Kubernetes-манифестов.
Helm и Docker
Docker отвечает за контейнерный образ, а Helm — за описание того, как этот образ должен быть развернут в Kubernetes.
Например, Docker image содержит приложение. Helm Chart определяет количество его реплик, Service, Ingress, переменные конфигурации и лимиты ресурсов.
| Docker | Helm |
|---|---|
| Упаковывает приложение | Описывает развертывание в Kubernetes |
| Создает container image | Создает Kubernetes-манифесты |
| Отвечает за содержимое контейнера | Отвечает за параметры запуска в кластере |
Dependencies в Helm
Chart может зависеть от других Charts.
Например, приложению требуется дополнительный компонент, который распространяется как отдельный пакет.
Зависимости позволяют включать такие компоненты в общую структуру и управлять их версиями.
Однако слишком большое количество жестко связанных зависимостей может усложнить обновление и сопровождение.
Subchart
Subchart — Chart, который используется как зависимость другого Chart.
Главный Chart может передавать ему определенные настройки и включать или отключать отдельные компоненты.
Такая модель удобна для составных приложений, но требует понятной структуры Values.
Helm и Secrets
В values могут использоваться параметры, необходимые приложению, но хранить реальные пароли и токены прямо в открытом Git-репозитории опасно.
Даже если значение удалить позднее, оно может сохраниться в истории Git.
Для секретов желательно использовать специализированные системы управления секретами или защищенные механизмы CI/CD.
Helm упрощает передачу конфигурации, но values.yaml не должен превращаться в открытое хранилище паролей и API-ключей.
ConfigMap и Helm
Helm удобно использовать для генерации ConfigMap.
Например, в values задаются параметры приложения, а template формирует из них Kubernetes ConfigMap.
Так различия между development и production остаются в Values, а структура ConfigMap управляется централизованным Chart.
Ingress и Helm
Helm Chart часто содержит шаблон Ingress для публикации приложения.
В values можно указать доменное имя и другие параметры.
Например, один и тот же Chart разворачивается в test с доменом test.example.ru и в production с example.ru.
Это позволяет избежать копирования почти одинаковых Ingress-манифестов.
Resources в Helm Chart
В Chart желательно предусматривать requests и limits ресурсов Kubernetes.
Разные окружения могут использовать разные значения CPU и памяти.
Например, тестовая среда получает минимальные ресурсы, а production — больше памяти и процессорного времени.
Правильная параметризация делает Chart более универсальным.
Readiness и Liveness Probes
Chart может включать параметры проверок состояния приложения.
Readiness Probe помогает Kubernetes понять, готов ли pod принимать трафик. Liveness Probe позволяет определить, требуется ли перезапуск контейнера.
Стандартные шаблоны помогают не забывать эти важные настройки при развертывании новых сервисов.
Helm Hooks
Hooks позволяют запускать определенные Kubernetes-ресурсы на отдельных этапах жизненного цикла release.
Например, можно выполнить Job перед обновлением или после установки.
Hooks полезны для специальных операций, но усложняют жизненный цикл приложения. Их следует использовать только там, где это действительно необходимо.
Миграции базы данных и Helm
Один из сложных сценариев — изменение схемы базы данных при обновлении приложения.
Можно запускать миграцию как отдельную Kubernetes Job, но необходимо учитывать порядок обновления, совместимость версий и возможность rollback.
Если новая версия базы несовместима со старым приложением, простой откат Helm release может не вернуть систему в рабочее состояние.
Поэтому миграции данных требуют отдельной стратегии.
Что такое helm lint
Lint используется для проверки Chart на распространенные ошибки и проблемы структуры.
Такую проверку полезно запускать автоматически в CI перед публикацией новой версии пакета.
Она не гарантирует, что приложение успешно заработает в реальном кластере, но помогает обнаружить часть проблем заранее.
Рендеринг шаблонов перед установкой
Перед применением Chart полезно посмотреть итоговые Kubernetes-манифесты.
Это позволяет убедиться, что Values подставились правильно, имена ресурсов корректны, а условная логика работает ожидаемым образом.
Особенно важно выполнять такую проверку после значительных изменений templates.
Helm и GitOps
Helm часто используется в GitOps-процессах.
В Git хранится Chart или набор Values, которые описывают желаемую конфигурацию приложения.
GitOps-система отслеживает изменения репозитория и синхронизирует их с Kubernetes.
В такой архитектуре Git становится основным источником информации о том, какая версия и конфигурация должна работать в кластере.
Helm и Argo CD
Системы GitOps могут использовать Helm Charts как источник Kubernetes-манифестов.
Например, в Git хранится Chart и production values. Система развертывания генерирует манифесты и синхронизирует их с кластером.
При этом управление жизненным циклом может отличаться от классического ручного запуска Helm, поэтому важно понимать выбранную модель эксплуатации.
Helm и SRE
SRE-команды используют Helm для стандартизации развертывания приложений и инфраструктурных компонентов Kubernetes.
Например, общий Chart может требовать обязательные probes, resource limits, labels и настройки мониторинга.
Это помогает уменьшать количество уникальных конфигураций и упрощает эксплуатацию большого числа сервисов.
Helm и Observability
Многие системы мониторинга и Observability распространяются как Helm Charts.
Это позволяет быстро устанавливать в Kubernetes Prometheus, Grafana, OpenTelemetry Collector и другие компоненты.
Однако готовый Chart все равно требует настройки под конкретный кластер: ресурсов, хранения данных, безопасности и отказоустойчивости.
Преимущества Helm
- уменьшает количество дублирующихся YAML-файлов;
- позволяет переиспользовать шаблоны;
- поддерживает разные Values для окружений;
- упрощает установку сложных приложений;
- хранит историю releases;
- поддерживает rollback;
- удобно интегрируется с CI/CD;
- подходит для GitOps;
- позволяет распространять приложения как готовые Charts;
- помогает стандартизировать Kubernetes-развертывания.
Недостатки и риски Helm
Helm упрощает управление манифестами, но добавляет собственный уровень шаблонизации.
Если Chart становится слишком сложным, понять итоговую конфигурацию бывает труднее, чем обычные YAML-файлы.
- сложные templates трудно читать;
- большое количество Values затрудняет сопровождение;
- ошибка общего Chart может затронуть множество приложений;
- rollback не обязательно откатывает данные;
- Secrets нельзя бездумно хранить в values;
- необходимо контролировать версии Charts;
- готовые публичные Charts требуют проверки перед production.
Типичные ошибки при использовании Helm
- Создавать слишком сложную логику templates.
- Хранить секреты в открытом values.yaml.
- Использовать один огромный Chart для несвязанных приложений.
- Не фиксировать версии зависимостей.
- Обновлять production без проверки итоговых манифестов.
- Считать rollback гарантированным откатом базы данных.
- Не задавать resources и probes.
- Копировать Chart для каждого окружения вместо использования разных Values.
- Использовать неизвестные публичные Charts без анализа.
- Не тестировать обновления перед production.
Как создать хороший Helm Chart
Шаг 1. Определить границы приложения
В один Chart следует объединять логически связанные Kubernetes-ресурсы.
Шаг 2. Вынести параметры в Values
Количество реплик, Docker image, домены и ресурсы не следует жестко фиксировать без необходимости.
Шаг 3. Не усложнять Templates
Шаблоны должны оставаться понятными инженеру, который будет сопровождать их через год.
Шаг 4. Добавить проверки
Chart полезно проверять через lint и рендеринг итоговых манифестов.
Шаг 5. Версионировать пакет
Изменения Chart должны сопровождаться понятным обновлением версии.
Шаг 6. Проверить обновление и rollback
Перед production следует протестировать реальные сценарии изменения версии.
Шаг 7. Исключить секреты
Пароли и токены должны передаваться через безопасные механизмы.
Практический пример
Компания развивает SaaS-приложение из нескольких Kubernetes-ресурсов. Для каждого окружения раньше существовал отдельный набор YAML-файлов.
В test использовалось две реплики, в staging — три, а в production — шесть. Кроме количества реплик отличались домены, ресурсы и настройки Ingress.
После нескольких месяцев файлы начали расходиться, и исправление, добавленное в production, случайно не попало в test.
Команда создала единый Helm Chart. Общая структура Deployment, Service и Ingress теперь хранится в templates, а различия между окружениями — в отдельных Values.
CI/CD собирает Docker-образ и передает его версию в Helm при развертывании.
После релиза с ошибкой команда использовала историю release для возврата к предыдущей конфигурации. При этом миграции базы управлялись отдельным процессом, поскольку их нельзя было безопасно откатить только средствами Helm.
В результате количество дублирующихся YAML-файлов уменьшилось, а развертывания стали более единообразными.
Helm для бизнеса
Helm имеет практическую ценность прежде всего для компаний, которые уже используют Kubernetes и регулярно разворачивают приложения.
Если десятки команд создают Kubernetes-манифесты независимо, инфраструктура быстро становится неоднородной.
Стандартные Helm Charts позволяют централизовать лучшие практики и сделать запуск новых сервисов быстрее.
Например, типовой корпоративный Chart может сразу включать мониторинг, probes, ограничения ресурсов и базовые параметры безопасности.
Когда нужен Helm
- компания использует Kubernetes;
- приложение состоит из нескольких Kubernetes-ресурсов;
- есть development, staging и production;
- нужно уменьшить дублирование YAML;
- требуются повторяемые установки;
- используется CI/CD;
- применяется GitOps;
- необходимо распространять стандартные приложения между командами;
- важно хранить историю развертываний.
Когда Helm может быть избыточным
Для очень простого приложения из одного или двух стабильных Kubernetes-манифестов добавление шаблонизации Helm может быть неоправданным.
Если конфигурация никогда не переиспользуется и не отличается между окружениями, обычные YAML-файлы могут быть понятнее.
Helm становится особенно полезен при росте количества ресурсов, окружений и повторяемых развертываний.
Связанные термины
| Термин | Связь с Helm |
|---|---|
| Kubernetes | Платформа, для которой Helm управляет пакетами приложений |
| Helm Chart | Пакет с шаблонами и конфигурацией Kubernetes-приложения |
| Release | Конкретная установка Chart в кластере |
| Values | Параметры, используемые при генерации манифестов |
| Template | Шаблон Kubernetes-манифеста |
| kubectl | Инструмент прямого управления Kubernetes-ресурсами |
| Terraform | IaC-инструмент, часто создающий инфраструктуру под Kubernetes |
| Infrastructure as Code | Подход к декларативному и версионируемому управлению инфраструктурой |
| CI/CD | Автоматизирует установку и обновление Helm releases |
| GitOps | Подход, при котором Helm-конфигурации могут храниться в Git как желаемое состояние |
| Docker | Создает container image, который Helm помогает развернуть в Kubernetes |
| SRE | Использует стандартизированные Charts для надежной эксплуатации приложений |
Краткий итог
Helm — пакетный менеджер для Kubernetes, который объединяет связанные Kubernetes-манифесты в переиспользуемые Charts и позволяет управлять их установкой как единым приложением.
Основными понятиями Helm являются Chart, Release, Templates и Values. Chart описывает приложение, Values задают параметры, Templates формируют Kubernetes-манифесты, а Release представляет конкретную установку в кластере.
Helm особенно полезен при наличии нескольких окружений, CI/CD, GitOps и большого количества Kubernetes-приложений. Он уменьшает дублирование YAML и помогает стандартизировать развертывания. При этом сложность шаблонов необходимо контролировать, секреты не следует хранить в открытых Values, а rollback приложения нельзя считать автоматическим откатом изменений данных.
