Начало работы с Helm‑чартами для Kubernetes

Обложка: руководство по началу работы с Helm‑чартами для Kubernetes

Быстрые ссылки

Что такое Helm‑чарт?
Установка Helm
Создание чарта
Установка чарта
Обновление, получение и удаление релизов
Писать чарт с нуля
Отладка и распространённые ошибки
Лучшие практики и безопасность
Чеклисты ролей и SOP
Итог

Важно: если вы только начинаете, сначала настройте kubectl и убедитесь, что у вас есть корректный kubeconfig и контекст кластера.

Что такое Helm‑чарт?

Однострочное определение: Helm‑чарт — это пакет Kubernetes‑манифестов с метаданными и шаблонами, который Helm умеет устанавливать, обновлять и откатывать как единое приложение.

Helm переносит знакомую модель пакетных менеджеров (apt, npm) в мир Kubernetes. Чарт может содержать зависимости, шаблоны и значения по умолчанию. При установке верхнеуровневого чарта Helm автоматически разворачивает все дочерние компоненты и зависимости.

Ключевые возможности:

Версионирование чарта (semantic versioning). Это упрощает откат к рабочему релизу.
Шаблонирование: значения можно задавать в values.yaml и переопределять при установке.
Поддержка зависимостей и локальных подкаталогов charts.

Краткая справочная карточка

Формат: директория чарта с файлами Chart.yaml, values.yaml, шаблонами в templates и опционально charts.
Основной поток: helm install → helm upgrade → helm rollback → helm uninstall.
Общие команды: helm create, helm lint, helm package, helm repo.

Установка Helm

Helm распространяется как бинарный файл в релизах проекта на GitHub. Скачайте дистрибутив для вашей ОС, сделайте файл исполняемым и поместите его в каталог в PATH.

Helm также доступен в пакетных менеджерах: Homebrew (macOS), apt/yum (Linux‑репозитории) и Chocolatey или Scoop на Windows.

После установки проверьте версию:

helm version

Пример с шаблоном вывода:

$ helm version --template='Version: {{.Version}}'

Version: v3.8.1

Helm использует текущую конфигурацию kubectl: активный kubeconfig и контекст будут применяться для всех команд Helm. При необходимости можно указать другой kubeconfig через переменную окружения KUBECONFIG или флаг –kubeconfig.

Создание Helm‑чарта

Helm может сгенерировать каркас чарта за пару команд. Это удобно для быстрого старта.

Создадим новый чарт командой:

$ helm create my-app-chart

В результате появится директория my-app-chart с набором файлов и поддиректорий. Просмотр содержимого:

$ ls my-app-chart

Chart.yaml charts templates values.yaml

Назначение основных элементов:

Chart.yaml — метаданные чарта (имя, версия, тип).
values.yaml — значения по умолчанию для шаблонов. Их можно переопределять при установке.
templates — каталог с Kubernetes‑манифестами в виде шаблонов Go‑template.
charts — вложенные чарты‑зависимости (можно удалить если не используется).

По умолчанию Helm создаёт пример для NGINX: Deployment, Service, Ingress и др. Шаблоны используют переменные из values.yaml — например, тег образа, порт сервиса и адрес Ingress.

Пример части values.yaml:

# Default values for my-app-chart.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount: 1

image:
  repository: nginx
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: ""

...

Примечание: в реальных чартах values.yaml обычно документируется — комментарии должны объяснять каждое поле.

Установка чарта

Установим приложение с помощью helm install:

$ helm install my-app .

Пример вывода при успешной установке:

NAME: foo

LAST DEPLOYED: Tue Mar 29 14:47:48 2022

NAMESPACE: default

STATUS: deployed

REVISION: 1

NOTES:

...

Первый аргумент — имя релиза, второй — путь к корню чарта (можно использовать “.”). Раздел NOTES содержит информацию, подготовленную автором чарта.

Переопределение значений при установке делает команда –set:

$ helm install my-app . --set replicaCount=3 --set image.tag=1.20

Это создаст три реплики контейнера nginx:1.20. Список Pod’ов можно проверить kubectl get pods.

Пример вывода kubectl:

$ kubectl get pods

NAME READY STATUS RESTARTS AGE

my-app-my-app-chart-6d6577749c-2qbhb 1/1 Running 0 61s

my-app-my-app-chart-6d6577749c-wdmgv 1/1 Running 0 44s

my-app-my-app-chart-6d6577749c-x5wp7 1/1 Running 0 40s

Обновление, получение и удаление релизов

Если чарт уже установлен, повторный helm install с тем же именем выдаст ошибку “несколько релизов с одинаковым именем”. Чтобы внести изменения, используйте helm upgrade — это создаст новую ревизию релиза.

Неправильная попытка:

$ helm install my-app . --set replicaCount=5

Ошибка: INSTALLATION FAILED: cannot re-use a name that is still in use

Правильно — выполнить upgrade:

$ helm upgrade my-app . --set replicaCount=5

Helm ответит, что релиз обновлён и применит новые манифесты.

Получить список релизов:

$ helm list

Пример вывода:

NAME    NAMESPACE   REVISION    UPDATED                         STATUS    CHART                 APP VERSION

my-app  default     2           2022-03-30 15:09:34.370758719   deployed  my-app-chart-0.1.0    1.16.0

Чтобы удалить релиз и удалить все объекты из кластера:

$ helm uninstall my-app

Пример: релиз будет удалён.

Писать чарт с нуля

Создадим простой чарт вручную. Создайте директорию cloudsavvy-chart и добавьте Chart.yaml с метаданными:

apiVersion: v2
name: cloudsavvy-chart
description: An example Helm chart.
type: application
version: 0.1.0
appVersion: 1.1.0

Пояснение полей:

type обычно application. Library — для переиспользуемых вспомогательных библиотек.
version — версия чарта (инкрементировать при изменении шаблонов).
appVersion — версия основного ПО, которое будет развернуто.

Добавим values.yaml:

deploymentName: cloudsavvy
image: nginx:latest
replicas: 1

И шаблон deployment в templates/deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.deploymentName }}-deployment
spec:
  selector:
    matchLabels:
      app: {{ .Values.deploymentName }}
  replicas: {{ .Values.replicas }}
  template:
    metadata:
      labels:
        app: {{ .Values.deploymentName }}
    spec:
      containers:
        - name: {{ .Values.deploymentName }}
          image: {{ .Values.image }}

В шаблонах значения из values.yaml доступны через {{ .Values.FIELD }}.

Установим чарт с переопределением replica:

$ helm install cloudsavvy-app . --set replicas=3

Проверим Pod’ы:

$ kubectl get pods

NAME READY STATUS RESTARTS AGE

cloudsavvy-deployment-7b975bd985-5r7dc 0/1 ContainerCreating 0 15s

cloudsavvy-deployment-7b975bd985-bpbkm 0/1 ContainerCreating 0 15s

cloudsavvy-deployment-7b975bd985-jzb5q 0/1 ContainerCreating 0 15s

Отладка и распространённые ошибки

Ниже — список типичных проблем и быстрые способы диагностики.

Ошибка “cannot re-use a name that is still in use”: используйте helm upgrade или удалите старый релиз helm uninstall.
Неправильный шаблон (render error): запустите helm lint и helm template для локальной рендерации шаблонов и отладки.

$ helm lint ./my-chart
$ helm template ./my-chart --values values.yaml

Конфликты версий API (например apps/v1beta1): обновите apiVersion манифестов согласно версии Kubernetes в кластере.
Права доступа: ошибки создания ресурсов могут быть вызваны RBAC. Проверьте ServiceAccount, роли и привязки ролей.
Неверные значения в values.yaml: используйте строгую валидацию и document values. В больших чартах добавляйте schema.yaml (OpenAPI v3 schema) для валидации значений.

Советы по отладке:

helm get manifest — посмотреть применённые манифесты.
kubectl describe / kubectl logs — стандартные инструменты Kubernetes для диагностики проблем с Pod’ами.
helm history и helm rollback — вернуть предыдущую рабочую ревизию.

Когда Helm не подходит: контрпримеры и альтернативы

Helm отлично подходит для упакованных приложений, но есть сценарии, где стоит рассмотреть другие варианты:

Если вам нужен полностью декларативный, GitOps‑центристский поток с декларативным синхронизатором, подумайте о Flux или Argo CD.
Для простого патча существующих манифестов без шаблонов удобен kustomize — он применяет разницы поверх YAML без шаблонных языков.
Если команда не хочет вводить шаблонизацию и предпочитает минимализм, используйте plain YAML и CI‑скрипты.

Ментальные модели при выборе:

Helm — как пакетный менеджер (толстая абстракция над набором манифестов).
Kustomize — как набор патчей и оверлейов поверх YAML.
GitOps (Argo CD/Flux) — как «истина в Git» с автоматическим применением в кластер.

Лучшие практики и рекомендации по безопасности

Подписывайте пакеты и используйте TLS для Helm рпо (если используете chart repository).
Не храните секреты в values.yaml в открытом виде; используйте SealedSecrets, HashiCorp Vault, External Secrets или Kubernetes Secret, зашифрованные в CI.
Используйте schema validations (values.schema.json) для проверки входных значений.
Ограничьте привилегии ServiceAccount ваших приложений по принципу least privilege.
Проверяйте используемые контейнерные образы на уязвимости и указывайте конкретные версии образов, избегая latest в production.

Пример политики безопасности:

Образ: хранить в приватном реестре и использовать immutable теги (sha256).
RBAC: отдельные роли для каждого неймспейса приложения.
NetworkPolicy: ограничить исходящий и входящий трафик Pod’ов.

Чеклисты ролей

Разделённые обязанности упрощают поддержку чарта в команде.

Разработчик приложения

Проверить, что Dockerfile и образ собираются и запускаются локально.
Добавить конфигурацию в values.yaml с понятными значениями по умолчанию.
Написать unit‑тесты шаблонов (helm unittest или helm template + yamllint).

SRE/Platform инженер

Добавить liveness/readiness probes в шаблоны.
Настроить ресурсы requests/limits.
Настроить мониторинг (Prometheus metrics, ServiceMonitor если Prometheus Operator).
Обеспечить CI/CD для публикации чарта в репозиторий.

Релиз‑менеджер

Версионировать chart (semver).
Тестировать установку/обновление/откат в staging перед production.
Документировать NOTES и инструкции в Chart.yaml/README.

SOP для релизов чарта (микро‑процесс)

Обновление шаблонов → увеличить chart.version.
Прогнать helm lint и unit‑тесты.
Выполнить helm template для проверки итогового YAML.
Запустить в staging: helm upgrade –install . –namespace staging –set …
Мониторинг: убедиться, что Pods готовы и метрики стабильны.
При успешной проверке продвинуть в production через CI/CD pipeline.
При проблемах: helm rollback и анализ.

Тесты и критерии приёмки

Критерии приёмки базового чарта перед продвижением в production:

helm lint завершился без ошибок.
Подготовленные манифесты корректно рендерятся (helm template).
Все Pod’ы переходят в состояние Ready за приемлемое время.
Метрики и логинги не показывают ошибок старта.
Интеграционные smoke‑tests успешны.

Полезные команды — шпаргалка

helm create — сгенерировать скелет чарта.
helm lint — статическая проверка чарта.
helm install — установить чарт.
helm upgrade — обновить релиз.
helm uninstall — удалить релиз.
helm list — список релизов.
helm repo add/helm repo update — работа с репозиториями.
helm package — упаковать чарт в tgz.
helm push (плагин) — отправить чарт в репозиторий.

Альтернативные подходы и сравнение

Сравнение в общих чертах:

Helm: сильная сторона — пакетирование, шаблонизация, версия чарта.
Kustomize: сильная сторона — overlay‑ы без шаблонов.
Flux/Argo CD: сильная сторона — GitOps, непрерывная синхронизация.

Выбор зависит от требований команды: нужен ли пакетный рынок чарта (Helm), или важна строгая декларативность Git (Argo CD), или требуется простая композиция YAML (Kustomize).

Миграция и совместимость

При миграции YAML из старых версий API обновите apiVersion ресурсов (например, Deployment → apps/v1).
Проверяйте совместимость Helm v2 → v3: если у вас есть старые релизы v2, потребуется миграция с helm 2to3 плагином.
Be careful с immutable fields: некоторые поля Kubernetes не позволяют их менять в уже созданных объектах; в таких случаях Helm может предложить recreate или manual intervention.

Пример расширенного values.yaml (шаблон для продакшн)

replicaCount: 3
image:
  repository: my-registry.example.com/my-app
  tag: 1.2.3
  pullPolicy: IfNotPresent
service:
  type: ClusterIP
  port: 80
resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "512Mi"
livenessProbe:
  httpGet:
    path: /health
    port: 80
  initialDelaySeconds: 30
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /ready
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 10
nodeSelector: {}
 tolerations: []
 affinity: {}

Шаблон контроля версий и релизов

Всегда повышайте chart.version при изменениях шаблонов.
Изменения appVersion отражают изменения в пакете ПО, которые чарт разворачивает.
Тегайте пакеты чарта (chart-0.1.0.tgz) и храните их в артефактном репозитории.

Меры по защите конфиденциальных данных и соответствие

Не храните секреты в открытом виде в репозитории чарта.
Для хранения секретов используйте интеграцию с Vault, SealedSecrets или External Secrets.
При работе с персональными данными удостоверитесь, что логирование не записывает чувствительные поля.

Примечание о GDPR: Helm сам по себе не обрабатывает данные пользователей, но приложения, которые вы разворачиваете через Helm, должны соответствовать правилам обработки персональных данных. Обратите внимание на хранение логов и бэкапов, где могут попадать персональные данные.

Decision flowchart — выбрать Helm или альтернативу

flowchart TD
  A[Нужно быстро упаковать приложение?] -->|Да| B[Helm]
  A -->|Нет| C[Нужна декларативность в Git?]
  C -->|Да| D[Flux/Argo CD]
  C -->|Нет| E[Использовать plain YAML или Kustomize]
  B --> F{Требуется шаблонизация}
  F -->|Да| B
  F -->|Нет| E

Примеры отказов и при каких условиях Helm не помогает

Если настройка окружения сильно отличается между деплойментами и требует сложных conditional‑правил, шаблоны могут стать трудно поддерживаемыми.
При сильной зависимости от секретов и ключей считается безопаснее интегрировать secret manager и избегать хранения секретов в values.
Если в организации запрещены дополнительные инструменты, возможно проще использовать встроенные CI/CD пайплайны для раскатки plain YAML.

Итог

Helm — мощный инструмент для пакетирования и управления приложениями в Kubernetes. Он упрощает повторяемые деплои, управляет версиями и предоставляет гибкую систему шаблонов. В этой статье мы разобрали базовую работу с helm create, helm install, helm upgrade и helm uninstall, объяснили структуру чарта, добавили советы по безопасности, чеклисты для ролей и операционные SOP.

Важно: начните с простого чарта, добавьте валидацию значений и автоматические тесты, а затем развивайте чарт согласно требованиям вашей команды и инфраструктуры.

Ключевые шаги для старта

Установите Helm и настройте kubeconfig.
Сгенерируйте чарт через helm create или создайте вручную Chart.yaml и values.yaml.
Протестируйте рендеринг через helm template и прогоните helm lint.
Установите в staging, прогоните smoke‑tests и затем переходите в production через helm upgrade.

Если вы хотите, я могу сгенерировать готовый шаблон values.yaml и полный пример чарта для вашего конкретного приложения (укажите стек: образ, порты, probes, требуемые ресурсы).