Команды Helm CLI — это основной инструмент для повседневной работы с Kubernetes. Эта шпаргалка объединяет все ключевые команды для поиска, проверки, установки и управления релизами в одном месте. Вы получите готовый справочник, который сэкономит время и снизит риск ошибок при работе с чартами, от предварительной проверки шаблонов до безопасного отката проблемных обновлений.
Начало работы: настройка репозиториев и поиск чартов
Перед установкой любого приложения необходимо подключить репозиторий с чартами и найти в нем нужный пакет. Этот этап закрывает базовую потребность в эффективной работе с источниками зависимостей.
Добавление, обновление и список репозиториев
Первая операция — добавление репозитория. Основные команды:
helm repo add <repo-name> <repo-url>— добавляет новый репозиторий. Например, для добавления стабильного репо Bitnami:helm repo add bitnami https://charts.bitnami.com/bitnami. Можно добавить и локальный путь:helm repo add local ./path/to/charts.helm repo update— обновляет локальный кеш информации о доступных чартах во всех добавленных репозиториях. Выполняйте эту команду регулярно, чтобы видеть последние версии пакетов.helm repo list— выводит список всех подключенных репозиториев, их URL и дату последнего обновления.
Без выполнения helm repo update команда поиска может показывать устаревшие версии чартов.
Поиск чартов в репозиториях
Для поиска пакетов в уже добавленных репозиториях используется команда helm search repo.
helm search repo nginx— найдет все чарты, в названии или описании которых есть «nginx».helm search repo bitnami/nginx --versions— выведет все доступные версии чарта nginx из репозитория bitnami.helm search hub nginx— выполняет поиск в публичном Artifact Hub, что полезно для первичного обнаружения чартов перед их добавлением.
Используйте --versions, чтобы увидеть полный список версий и избежать установки устаревшего пакета.
Безопасная установка и обновление релизов: проверка перед применением
Страх «сломать рабочую среду» — главная боль при деплое. Helm предоставляет набор инструментов для предварительной проверки, которые позволяют убедиться в корректности чарта перед реальным применением в кластере.
Предварительная проверка чарта: lint и template
Первый этап — статический анализ чарта.
helm lint ./mychart— проверяет структуру и синтаксис чарта на соответствие стандартам. Команда сообщит об ошибках вChart.yaml, отсутствующих обязательных файлов или проблемах с шаблонами. Например, вывод[ERROR] templates/: render error in "mychart/templates/deployment.yaml": template: mychart/templates/deployment.yaml:10: unexpected EOFукажет на синтаксическую ошибку в шаблоне.helm template my-release ./mychart— рендерит итоговые манифесты Kubernetes, применяя все значения по умолчанию и переопределения. Это позволяет визуально проверить, какие именно ресурсы (Deployments, Services, ConfigMaps) будут созданы в кластере, без их реального применения.
Всегда запускайте helm lint перед упаковкой или установкой чарта.
Симуляция установки и отладка: флаги --dry-run и --debug
Следующий шаг — полная симуляция деплоя.
helm install my-release ./mychart --dry-run— симулирует процесс установки. Helm выполнит все проверки, сгенерирует манифесты, но не отправит их в API Kubernetes. В выводе вы увидите имена создаваемых ресурсов, что позволяет проверить корректность имен и неймспейсов.helm install my-release ./mychart --dry-run --debug— добавляет к симуляции вывод сгенерированных манифестов в формате YAML. Флаг--debugособенно полезен, когда нужно проверить итоговые значения переменных или конфигурации после обработки всех шаблонов и функций.
Разница между флагами: --dry-run показывает, что *будет* сделано, а --debug показывает *как* это будет сделано, включая детали шаблонизации. В production-средах выполнение --dry-run должно стать обязательным шагом перед каждой установкой или обновлением.
Управление жизненным циклом релиза: установка, обновление, откат
После проверки наступает этап реального управления приложением. Этот блок команд формирует полный рабочий цикл для поддержки релизов.
Установка и обновление релиза
Базовые операции деплоя и их контроль.
- Установка:
helm install my-release bitnami/nginx— установка из репозитория.helm install my-release ./mychart -f values.yaml— установка локального чарта с переопределением значений из файла.helm install my-release ./mychart --set image.tag="v1.2.0"— установка с inline-переопределением параметров.
- Обновление:
helm upgrade my-release bitnami/nginx --version 15.0.0— обновление релиза до конкретной версии чарта.helm upgrade my-release ./mychart -f new-values.yaml— обновление конфигурации.- Ключевые флаги для контроля:
--wait— ждет, пока все Pods не перейдут в состояние Ready.--timeout 5m— устанавливает таймаут операции.--atomic— при неудаче автоматически откатывает изменения.--reuse-values— повторно использует значения, установленные в предыдущей ревизии, что удобно при обновлении только версии чарта.
Команда helm upgrade — основная операция для поддержки приложений, позволяющая безопасно вносить изменения.
Откат на предыдущую версию и просмотр истории
Решение на случай проблем после обновления.
helm history my-release— выводит таблицу всех ревизий релиза с номерами, статусами (deployed, failed, superseded), описаниями и временем. Это главный инструмент для анализа изменений.helm rollback my-release 2— откатывает релиз «my-release» к ревизии номер 2. Helm создаст новую ревизию (например, 4), которая будет точной копией состояния ревизии 2.
Перед откатом всегда проверяйте helm history, чтобы убедиться, что целевая ревизия была стабильной. Для полного удаления релиза используйте helm uninstall my-release (в Helm 2 — helm delete).
Работа с зависимостями и управление чартами
Сложные чарты часто зависят от других чартов (например, база данных для приложения). Управление этими зависимостями — рутинная, но важная задача.
Зависимости объявляются в файле Chart.yaml в разделе dependencies (в Helm 3; в Helm 2 использовался отдельный файл requirements.yaml). Ключевые команды:
helm dependency update ./mychart— скачивает все зависимости, указанные вChart.yaml, из их репозиториев и упаковывает их в архивcharts/. Эта команда обращается к сети.helm dependency build ./mychart— пересобирает зависимости из уже существующего архиваcharts/. Полезно, когда зависимости уже загружены локально, и нужно их обновить без доступа к сети.
После выполнения этих команд в директории чарта появится папка charts/ с распакованными зависимостями, готовыми к установке вместе с основным чартом.
Продвинутые сценарии и отладка проблем
Для диагностики сложных проблем и выполнения специфичных задач Helm предоставляет дополнительные инструменты.
Получение детальной информации о релизе
Команда helm get извлекает конкретные данные о развернутом релизе.
helm get manifest my-release— выводит все сгенерированные манифесты Kubernetes, которые были применены в кластере. Незаменима для проверки итоговой конфигурации.helm get values my-release— показывает все значения (values), с которыми был развернут релиз, включая значения по умолчанию и переопределения. Добавьте флаг--all, чтобы увидеть все значения, включая вычисляемые.helm get hooks my-release— отображает манифесты хуков (пред- и постустановочных jobs).helm get all my-release— объединяет вывод манифестов, значений, хуков и заметок (notes).
Эти команды полезны для документирования конфигурации или анализа расхождений между ожидаемым и реальным состоянием. Например, сравнение вывода helm template и helm get manifest помогает найти проблемы с подстановкой переменных.
Версии Helm и важные различия
Чтобы закрыть возражение «Инструкция не для моей версии ПО», важно отметить ключевые изменения. Все команды в этой шпаргалке приведены для Helm 3 (актуальной на 2026 год). Главное отличие от Helm 2 — отказ от архитектурного компонента Tiller, что повысило безопасность. Это повлияло на синтаксис некоторых команд:
- Helm 2:
helm delete --purge my-release - Helm 3:
helm uninstall my-release(флаг--purgeне требуется, история хранится иначе).
Проверьте вашу версию командой helm version. Для большинства повседневных задач (установка, обновление, поиск) синтаксис команд между Helm 2 и 3 совпадает, но при работе с историей и удалением необходимо быть внимательным.
Для глубокой диагностики взаимодействия ресурсов в кластере, особенно при работе с Custom Resources (CR), может потребоваться анализ событий и логики контроллеров. В таких случаях методики, описанные в гайде по полной диагностике Custom Resources в Kubernetes, помогут систематизировать отладку, выходящую за рамки возможностей Helm CLI.