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

Проблема без Helm

Представь: тебе нужно задеплоить веб-приложение в Kubernetes. Оно состоит из:
- Deployment (основное приложение)
- Service (доступ к приложению)
- ConfigMap (конфигурация)
- Secret (пароли)
- Ingress (внешний доступ)
- HorizontalPodAutoscaler (масштабирование)

Это минимум 6 YAML файлов. При этом одно и то же приложение почти никогда не запускается одинаково во всех окружениях.

Например, в dev, staging и prod могут отличаться:

база данных: dev-postgres, staging-кластер PostgreSQL или production managed database;
адреса внешних API: sandbox платежей, staging CRM, production billing API;
переменные окружения: LOG_LEVEL, APP_ENV, PUBLIC_URL, CACHE_TTL;
feature flags: новая корзина включена только в dev, A/B тест включён только для staging;
настройки ресурсов: в dev 1 replica и маленькие лимиты, в prod 6 replicas и другие CPU/memory;
домены и пути Ingress: dev.example.internal, staging.example.com, app.example.com;
настройки health checks, autoscaling, annotations, labels и tolerations.

Если всё это хранить как набор почти одинаковых YAML, приходится либо копировать файлы для каждого окружения, либо постоянно править одни и те же поля руками.

Каждый раз при деплое на другой стенд (dev/staging/prod) тебе нужно вручную менять:
- namespace
- количество реплик
- образ и тег
- лимиты ресурсов
- URL для Ingress
- адреса сервисов, переменные окружения и feature flags

Десятки ручных изменений = ошибки гарантированы.

Главная проблема не в том, что YAML “длинный”. Длинный YAML можно читать. Проблема в повторяемости. Когда один и тот же набор ресурсов копируется для dev, staging и prod, отличия начинают жить в ручных правках. Один человек поменял image tag, другой забыл resources, третий поставил другой Ingress host. Через несколько релизов уже сложно понять, какой набор YAML является правильным.

Helm появился как ответ на этот практический вопрос: как упаковать Kubernetes-приложение так, чтобы его можно было устанавливать, настраивать, обновлять и откатывать как единый объект.

Важная идея: Helm нужен не потому, что Kubernetes YAML нельзя писать руками, а потому что набор связанных YAML нужно повторяемо настраивать и обновлять.

Один Deployment ещё можно применить вручную. Но приложение из Deployment, Service, ConfigMap, Secret, Ingress и разных values для окружений быстро требует упаковки, истории и проверки итогового render.

Ещё один сильный сценарий: не писать chart самому, а взять готовый универсальный chart из репозитория. Например, для nginx, PostgreSQL, Redis, ingress controller, monitoring stack или другого типового компонента. Автор chart уже описал Deployment, Service, ConfigMap, Secret, probes, volumes, RBAC и другие Kubernetes-объекты, а ты настраиваешь только values под свой кластер:

какой image tag использовать;
сколько replicas запустить;
какие resources поставить;
какой storage class и размер PVC выбрать;
какие env, secrets, ingress hosts и annotations включить;
какие компоненты chart включить или выключить.

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

Что такое Helm

Helm — пакетный менеджер для Kubernetes. Он превращает набор YAML файлов в Chart (чарт) — переиспользуемый пакет с переменными.

Helm Chart = шаблоны YAML + значения по умолчанию (values.yaml)

Аналогия: Helm для Kubernetes = apt для Ubuntu = npm для Node.js.

Эта аналогия полезна, но не идеальна. Helm не устанавливает бинарники в систему как apt. Он генерирует Kubernetes-манифесты и отправляет их в Kubernetes API. То есть результат работы Helm - всё те же Deployment, Service, ConfigMap, Secret и другие объекты, которые ты уже знаешь.

Упрощённая цепочка:

Chart + Values -> helm template -> Kubernetes YAML -> Kubernetes API -> реальные объекты

Если понимать эту цепочку, Helm перестаёт быть “магией”. Он просто помогает не писать и не копировать одинаковые YAML вручную.

В этой статье достаточно запомнить три слова:

Chart — пакет приложения;
Values — настройки, с которыми этот пакет устанавливается;
Release — конкретная установка chart'а в Kubernetes.

В следующей статье мы разберём эти три сущности подробно. Сейчас важна общая идея: Helm берёт chart, подставляет values и создаёт обычные Kubernetes-манифесты.

Основные команды

# Установить Chart
helm install my-release ./mychart

# Установить с кастомными values
helm install my-release ./mychart --set image.tag=v2.0

# Посмотреть установленные релизы
helm list

# Обновить релиз
helm upgrade my-release ./mychart

# Откатить на предыдущую версию
helm rollback my-release 1

# Удалить релиз
helm uninstall my-release

Преимущества Helm

Переиспользование — один chart для dev/staging/prod
Версионирование — каждый helm upgrade создаёт новую ревизию
Rollback — мгновенный откат командой helm rollback
Sharing — Charts можно публиковать в репозиториях
Templating — мощный Go template engine для любой логики

Важное ограничение: Helm не делает плохой Kubernetes-манифест хорошим. Если chart генерирует Deployment с неверным selector или Service с неправильным targetPort, Kubernetes будет вести себя так же, как если бы ты применил этот YAML вручную. Поэтому Helm нужно использовать вместе с привычкой смотреть итоговый render.

Локальный chart и chart из репозитория

В первых задачах ты работаешь с chart из локальной директории. Это удобно для обучения: все файлы перед глазами, можно открыть Chart.yaml, values.yaml и templates/.

В реальных командах charts часто берут из репозитория: внутреннего корпоративного Nexus/ChartMuseum или публичного репозитория вроде Bitnami. В этом курсе Bitnami chart доступен через Nexus mirror — это та же модель, которую часто используют для контролируемой поставки зависимостей. Для тебя команды остаются обычными Helm-командами: helm repo update, helm search repo, helm show values, helm pull.

Когда Helm не нужен

Helm полезен не всегда. Если у тебя один маленький манифест для учебного Pod'а, проще применить его через kubectl apply. Helm начинает окупаться, когда появляются повторяемость, окружения, releases и история изменений.

Примеры, где Helm может быть лишним:

одноразовый Pod для проверки команды;
маленький учебный манифест без параметров;
объект, который проще хранить как обычный YAML;
ситуация, где команда ещё не понимает Kubernetes-объекты и пытается спрятать их за chart.

Примеры, где Helm уместен:

приложение состоит из нескольких связанных ресурсов;
нужны разные values для dev/stage/prod;
нужно обновлять image tag без ручного копирования YAML;
важна история release и rollback;
chart нужно переиспользовать в нескольких командах или проектах.

Здоровая модель такая: сначала понимать Kubernetes YAML, потом использовать Helm для упаковки и повторяемости. Если Helm скрывает непонимание Deployment, Service или Ingress, диагностика станет только сложнее.

Дальше мы отдельно разберём Chart, Release и Values. Это нужно, чтобы в командах Helm понимать не только синтаксис, но и что именно меняется в кластере.