Быстрый старт с Helm в Kubernetes: создание чартов, управление зависимостями и обновление релизов без простоев | AdminWiki
Logo

Быстрый старт с Helm в Kubernetes: создание чартов, управление зависимостями и обновление релизов без простоев

25 августа 2026 8 мин. чтения
Содержание статьи

Введение в Helm: зачем он нужен и как работает

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

Аналогия с apt или yum здесь уместна. Как apt устанавливает пакет со всеми зависимостями одной командой, так и Helm разворачивает в кластере приложение со всеми его компонентами: Deployment, Service, ConfigMap, Ingress, PVC. При этом Helm не просто применяет манифесты, он отслеживает состояние релиза и позволяет вернуться к предыдущей версии одной командой.

Helm v3 работает без Tiller - серверной части, которая в версии 2 требовала расширенных прав в кластере и создавала поверхность для атак. Сейчас Helm - это клиентская утилита, которая взаимодействует с Kubernetes API напрямую через kubeconfig. Это повысило безопасность и упростило установку.

Основные концепции Helm: чарты, релизы, репозитории

Три термина определяют работу с Helm:

  • Чарт (chart) - коллекция файлов, описывающих набор ресурсов Kubernetes. Это каталог с метаданными, шаблонами и значениями по умолчанию. Чарт можно упаковать в архив .tgz для распространения.
  • Релиз (release) - экземпляр чарта, развернутый в конкретном кластере. Один чарт можно установить несколько раз с разными именами релизов, например, app-prod и app-staging.
  • Репозиторий (repository) - место хранения чартов. Это HTTP-сервер с файлом index.yaml, описывающим доступные чарты и их версии.

Пример: вы добавляете репозиторий Bitnami, устанавливаете чарт PostgreSQL как релиз db-prod, затем обновляете его до новой версии чарта. Все три концепции задействованы в этом сценарии.

Установка Helm и настройка окружения

Установка Helm на Linux выполняется через скрипт или пакетный менеджер. Наиболее прямой способ:

curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Для macOS используйте Homebrew:

brew install helm

Для Windows - Chocolatey:

choco install kubernetes-helm

Проверьте установку:

helm version

Вывод покажет версию клиента. Если кластер настроен корректно, Helm также отобразит версию Kubernetes. Для автодополнения команд в bash выполните:

helm completion bash > /etc/bash_completion.d/helm

Для zsh путь будет другим, но команда helm completion zsh сгенерирует нужный скрипт. Инициализация в Helm v3 не требуется: достаточно настроенного kubeconfig. Добавьте репозиторий с чартами:

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

Официальный репозиторий stable устарел и больше не поддерживается. Используйте Bitnami, artifacthub.io или собственные репозитории.

Создание первого чарта: пошаговое руководство

Команда helm create генерирует структуру чарта с рабочим примером:

helm create my-app

В каталоге my-app появятся файлы и подкаталоги. Разберем их назначение.

Структура чарта: Chart.yaml, values.yaml, templates

Chart.yaml - метаданные чарта. Минимальный набор полей:

apiVersion: v2
name: my-app
description: Пример чарта для быстрого старта
version: 0.1.0
appVersion: "1.16.0"

Поле apiVersion для Helm v3 всегда v2. Поле version - версия самого чарта, appVersion - версия приложения, которое чарт разворачивает.

values.yaml - значения по умолчанию. Здесь задаются параметры, которые подставляются в шаблоны. Пример с комментариями:

replicaCount: 2
image:
  repository: nginx
  tag: "1.25"
  pullPolicy: IfNotPresent
service:
  type: ClusterIP
  port: 80
resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 250m
    memory: 256Mi

templates/ - шаблоны Kubernetes-манифестов. Helm использует шаблонизатор Go templates. Значения из values.yaml подставляются через конструкцию {{ .Values.* }}. Пример deployment.yaml с параметризацией:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-deployment
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Release.Name }}
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: {{ .Values.service.port }}

Объект .Release содержит информацию о релизе: имя, пространство имен, версию. Объект .Chart - метаданные из Chart.yaml.

Шаблонизация с помощью Helm: функции и pipelines

Go templates в Helm поддерживают функции и pipelines. Функция quote оборачивает значение в кавычки:

image: {{ .Values.image.repository | quote }}

Функция default задает значение по умолчанию, если переменная пуста:

replicas: {{ .Values.replicaCount | default 1 }}

Условные операторы позволяют включать блоки по условию:

{{- if .Values.ingress.enabled }}
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: {{ .Release.Name }}-ingress
{{- end }}

Циклы range перебирают списки:

{{- range .Values.env }}
- name: {{ .name }}
  value: {{ .value }}
{{- end }}

Именованные шаблоны через define позволяют переиспользовать код. Определите блок в файле _helpers.tpl:

{{- define "my-app.labels" -}}
app: {{ .Release.Name }}
{{- end }}

Затем вызывайте его в любом шаблоне:

labels:
  {{- include "my-app.labels" . | nindent 2 }}

Установите чарт:

helm install my-release ./my-app

Просмотрите релизы:

helm list

Управление зависимостями между чартами

Зависимости позволяют включать другие чарты в ваш чарт. Например, ваше приложение требует PostgreSQL и Redis. Вместо ручного деплоя трех компонентов вы объявляете зависимости, и Helm устанавливает все сразу.

Объявление зависимостей в Chart.yaml

В Helm v3 зависимости объявляются в Chart.yaml в блоке dependencies:

dependencies:
  - name: postgresql
    version: 15.5.0
    repository: https://charts.bitnami.com/bitnami
  - name: redis
    version: 18.6.0
    repository: https://charts.bitnami.com/bitnami

После объявления выполните:

helm dependency update

Helm скачает чарты зависимостей в каталог charts/. Для локальных чартов укажите file:// в поле repository. Команда helm dependency build пересобирает зависимости из lock-файла.

Переопределение значений зависимостей

Значения подчартов задаются в values.yaml родительского чарта через имя зависимости как ключ:

postgresql:
  auth:
    username: myuser
    password: mypassword
    database: mydb
  primary:
    persistence:
      size: 20Gi
redis:
  architecture: standalone
  auth:
    enabled: false

Условные зависимости включаются через поле condition:

dependencies:
  - name: postgresql
    version: 15.5.0
    repository: https://charts.bitnami.com/bitnami
    condition: postgresql.enabled

Теперь в values.yaml можно управлять установкой подчарта:

postgresql:
  enabled: true

Теги tags позволяют включать группы зависимостей одной переменной.

Обновление релизов без простоев: стратегии и практика

Helm сам по себе не гарантирует zero-downtime. Он применяет манифесты, а за доступность отвечает Kubernetes. Стратегия обновления задается в Deployment, а Helm лишь передает новые параметры.

Настройка стратегии обновления в Deployment

Стратегия RollingUpdate постепенно заменяет поды. Пример для минимизации простоя:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1

maxUnavailable: 0 запрещает уменьшение количества работающих подов ниже желаемого. maxSurge: 1 позволяет создать один дополнительный под во время обновления. В сумме это дает: новый под поднимается, проходит проверки, затем старый удаляется. Трафик не прерывается.

Для корректного обновления обязательны пробы:

readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 20

ReadinessProbe определяет, когда под готов принимать трафик. LivenessProbe - когда под нужно перезапустить. Без readinessProbe Kubernetes считает под готовым сразу после старта, что при медленной инициализации приложения приведет к ошибкам.

Использование helm upgrade и helm rollback

Обновление релиза выполняется командой:

helm upgrade my-release ./my-app --values values-prod.yaml

Передача отдельных значений через --set:

helm upgrade my-release ./my-app --set image.tag=1.26 --set replicaCount=3

Флаг --reuse-values сохраняет значения предыдущего релиза, переопределяя только переданные:

helm upgrade my-release ./my-app --reuse-values --set image.tag=1.26

Просмотр истории релизов:

helm history my-release

Откат к предыдущей версии:

helm rollback my-release 2

Где 2 - номер ревизии из истории. Helm хранит до 10 ревизий по умолчанию. Для blue-green и canary стратегий Helm используется иначе: создаются два релиза с разными именами, а переключение трафика выполняется через Service или Ingress. Это выходит за рамки базового сценария, но Helm поддерживает такие подходы через манипуляцию labels и selector.

Лучшие практики и типичные ошибки при работе с Helm

Практические рекомендации, проверенные на production-кластерах:

  • Храните чарты в системе контроля версий. Каждое изменение должно проходить ревью.
  • Используйте семантическое версионирование для чартов. Изменение мажорной версии сигнализирует о несовместимых изменениях.
  • Не храните секреты в values.yaml. Используйте Kubernetes Secrets, внешние менеджеры секретов (Vault, Sealed Secrets) или переменные окружения.
  • Проверяйте чарты перед деплоем: helm lint ./my-app и helm template ./my-app для просмотра сгенерированных манифестов.
  • Для управления несколькими релизами используйте helmfile - декларативный способ описания всех релизов кластера.

Типичные ошибки:

  • Забыть выполнить helm dependency update после изменения зависимостей. Релиз падает с ошибкой отсутствия подчарта.
  • Неправильное использование --reuse-values. Если в новой версии чарта добавлены поля в values.yaml, они не применятся, и релиз может получить неполную конфигурацию.
  • Отсутствие проверки сгенерированных манифестов. Команда helm template показывает, что именно будет применено, до фактического деплоя.

Более детальный разбор структуры чарта с примерами для production вы найдете в руководстве по структуре Helm-чарта. Для быстрого доступа к командам CLI сохраните шпаргалку по командам Helm.

Интеграция Helm в CI/CD пайплайн

Helm встраивается в CI/CD как этап деплоя. Пример для GitHub Actions:

deploy:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - name: Install Helm
      run: |
        curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
    - name: Deploy
      run: |
        helm repo add bitnami https://charts.bitnami.com/bitnami
        helm repo update
        helm upgrade --install my-app ./my-app \
          --namespace production \
          --values values-prod.yaml \
          --wait --timeout 5m

Флаг --install устанавливает релиз, если его нет, и обновляет, если есть. Флаг --wait ожидает готовности всех ресурсов. Флаг --timeout ограничивает время ожидания.

Для декларативного управления используйте GitOps-инструменты: Argo CD или Flux. Они отслеживают состояние Git-репозитория и автоматически применяют изменения через Helm. Helmfile также подходит для CI/CD: он описывает все релизы в одном файле и применяет их одной командой.

Храните values для разных окружений отдельно: values-dev.yaml, values-staging.yaml, values-prod.yaml. Это позволяет переиспользовать один чарт для всех сред.

Сравнение Helm с другими инструментами управления Kubernetes

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

Выбор зависит от задачи. Если вы разворачиваете стандартные приложения (базы данных, мониторинг, ingress-контроллеры), Helm с готовыми чартами экономит часы. Если вы управляете собственными микросервисами с минимальными отличиями между окружениями, Kustomize может быть достаточен. Многие команды используют оба инструмента: Helm для инфраструктурных компонентов, Kustomize для приложений.

Перед обновлением кластера Kubernetes проверьте совместимость чартов. Чек-лист продакшн-ready Helm-чартов поможет избежать типичных проблем. Если вы мигрируете ingress-nginx, изучите руководство по миграции с Helm chart 4.x на 5.x без простоя.

Заключение: дальнейшие шаги в освоении Helm

Helm решает три ключевые задачи: упаковка приложений в чарты, управление зависимостями и обновление релизов с возможностью отката. Освоив базовые команды helm create, helm install, helm upgrade и helm rollback, вы закрываете большую часть повседневных задач деплоя в Kubernetes.

Дальнейшие темы для изучения: хуки (helm hooks) для выполнения действий на разных этапах жизненного цикла релиза, тестирование чартов через helm test, создание собственных репозиториев через ChartMuseum или Harbor. Практикуйтесь на реальных задачах: упакуйте существующее приложение в чарт, добавьте зависимости, настройте rolling update и проверьте откат. Это закрепит материал лучше любого теоретического руководства.

Поделиться:
Сохранить гайд? В закладки браузера