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

Обложка: как начать писать Helm-чарты для приложений Kubernetes

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

Что такое Helm-чарт?
Установка Helm
Создание чарта
Установка чарта
Обновление, просмотр и удаление релизов
Написание чарта вручную
Расширенные практики и CI/CD
Проверки, отладка и рекомендации
Краткое резюме

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

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

Ключевые идеи в одну строку:

Чарт = пакет Kubernetes-манифестов + шаблоны + values.yaml.
Релиз = установленный экземпляр чарта в кластере с версией и историей.
Шаблоны позволяют подставлять значения во время установки и обновления.

Важно: чарты версионируются семантически; это даёт простые откаты на известную рабочую версию.

Установка Helm

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

# пример для Linux/macOS
tar -zxvf helm-v3.x.x-linux-amd64.tar.gz
sudo mv linux-amd64/helm /usr/local/bin/helm

Helm также доступен в менеджерах пакетов: Homebrew, apt, dnf, Chocolatey и Scoop. После установки проверьте версию:

helm version

Пример форматированного вывода:

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

Version: v3.8.1

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

Создание Helm-чарта (scaffold)

Самый быстрый путь — сгенерировать шаблон чарта командой:

$ helm create my-app-chart

Это создаст каталог my-app-chart со следующей базовой структурой:

$ ls my-app-chart

Chart.yaml  charts  templates  values.yaml

Ключевые файлы и каталоги:

Chart.yaml — метаданные чарта: имя, версия, appVersion, описание.
values.yaml — значения по умолчанию, которые можно переопределять при установке.
templates — шаблоны Kubernetes-манифестов (deployment, service, ingress и т. д.).
charts — зависимости (вложенные чарты).

Пример начального values.yaml (сокращённо):

replicaCount: 1

image:
  repository: nginx
  pullPolicy: IfNotPresent
  tag: ""

service:
  type: ClusterIP
  port: 80

Helm по умолчанию создаёт пример с NGINX — это полезно для изучения, но в реальном приложении вы будете переопределять шаблоны и values под свои нужды.

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

Команда для установки чарта:

$ helm install my-app .

Параметры:

первый аргумент — имя релиза (release name), например my-app;
второй — путь к каталогу чарта (можно использовать .).

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

NAME: foo
LAST DEPLOYED: Tue Mar 29 14:47:48 2022
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
...

Чтобы переопределить значения из values.yaml, используйте –set или файл через -f/–values:

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

# или
$ helm install my-app . -f custom-values.yaml

Проверка подов через kubectl:

$ kubectl get pods

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

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

Обновление, просмотр и удаление релизов

Повторная установка с тем же именем выдаст ошибку — используйте upgrade для внесения изменений в уже развернутый релиз:

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

Список релизов:

$ 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

Удаление удаляет все Kubernetes-ресурсы, которые были созданы Helm.

Написание собственного чарта с нуля

Создадим простой чар트 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-чарты используются как зависимости и не содержат templates.

Пример values.yaml:

deploymentName: cloudsavvy
image: nginx:latest
replicas: 1

Создайте template 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 }}

Шаблоны используют синтаксис Go templates: {{ .Values.FIELD }}. Helm рендерит шаблоны, подставляя значения и генерируя окончательные YAML-манифесты.

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

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

Проверьте работу pod’ов:

$ kubectl get pods

Шаблонизация: функции, условия и циклы

Helm использует механизм шаблонов Go. Некоторые полезные конструкции:

Условные операторы: {{- if .Values.foo }}...{{- end }}
Циклы: {{- range $i, $e := .Values.list }}...{{- end }}
Встроенные функции: quote, default, include, toYaml, indent.

Пример: использование default и toYaml в ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "cloudsavvy.fullname" . }}-config
data:
{{ toYaml .Values.config | indent 2 }}

Совет: используйте tpl для рендеринга шаблонов, которые хранятся как строки в values.yaml.

Best practices и паттерны организации

Разделяйте шаблоны: один файл template на ресурс (Deployment, Service, HPA и т. д.).
Держите значения чувствительных данных за пределами values.yaml (используйте Secrets или интеграции типа Helm Secrets в CI).
Используйте Chart.yaml.version для версий чарта и appVersion для версии приложения.
Применяйте lint перед публикацией: helm lint ./my-chart.
Пишите NOTES.txt с инструкциями и post-install подсказками для пользователя.
Обеспечьте тесты чарта: добавьте папку tests с Job-манифестом для helm test.

Отладка и диагностика

Просмотреть рендеринг шаблонов локально:

$ helm template my-release . -f custom-values.yaml

Получить подробную информацию о релизе:

$ helm status my-app

Просмотреть историю релиза и откат:

$ helm history my-app
$ helm rollback my-app

Используйте --debug --dry-run при разработке, чтобы не вносить изменения в кластер:

$ helm install --debug --dry-run my-app .

CI/CD: как интегрировать Helm в пайплайн

Мини-методология внедрения Helm в CI/CD:

Линтинг: helm lint.
Тест рендеринга: helm template + k8s-validate (yaml/schema validation).
Unit-тесты чарта (helm-unittest или базовые шаблонные тесты).
Билд пакета: helm package.
Публикация в chart repository (ChartMuseum, GitHub Pages, OCI registry).
Применение в staging через helm upgrade --install с флагом --atomic.
Мониторинг и проверка smoke-тестов, затем прод-выпуск.

Пример snippet в CI (проще представить псевдокод):

- run: helm lint ./chart
- run: helm template ./chart -f values.ci.yaml | kubectl apply --dry-run=server -f -
- run: helm package ./chart
- run: helm push chart-0.1.0.tgz oci://registry.example.com/charts

Используйте --atomic для автоматического отката при ошибке установки.

Безопасность и управление секретами

Не храните секреты в values.yaml в репозитории.
Используйте внешние провайдеры: HashiCorp Vault, AWS Secrets Manager, SealedSecrets.
Для локального шифрования можно применить Helm Secrets (sops) — это популярный паттерн, но в CI нужно настроить доступ к ключам.

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

Если у вас только пара статичных YAML-файлов и ровно одно окружение, Helm может быть избыточен.
Для декларативного управления конфигурациями, где важна минимальная трансформация YAML, подойдёт Kustomize.
Если требуется простая композиция ресурсов без шаблонов — рассмотрите чистый GitOps-подход (Argo CD + Kustomize или kustomize overlays).

Решающее правило: выберите инструмент, который упрощает поддержание множества окружений и конфигураций. Helm — хорош для параметризуемых, многокомпонентных приложений.

Распространённые ошибки и как их избегать

Хранение чувствительных данных в открытом виде — используйте секреты/шифрование.
Сложные шаблоны без модулей — выносите повторяющийся код в _helpers.tpl.
Отсутствие тестов и lint — добавьте helm lint и helm template --debug в CI.
Установка директно в прод без проверки — применяйте staging и smoke-тесты.

Важно: проверяйте результат helm template перед применением, особенно если используете значения из CI/CD.

Примеры шаблонов и сниппеты (cheat sheet)

helpers.tpl (общие функции):

{{- define "cloudsavvy.fullname" -}}
{{- printf "%s-%s" .Release.Name .Chart.Name | trunc 63 | trimSuffix "-" -}}
{{- end -}}

Service manifest:

apiVersion: v1
kind: Service
metadata:
  name: {{ include "cloudsavvy.fullname" . }}
spec:
  type: {{ .Values.service.type | default "ClusterIP" }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: http
  selector:
    app: {{ .Values.deploymentName }}

Config-driven env vars:

env:
  - name: APP_ENV
    value: {{ .Values.environment | quote }}

Role-based чеклисты

Разработчик:

Локально прогоните helm template.
Напишите unit-tests для шаблонов (helm-unittest).
Не добавляйте секреты в values.yaml в репозиторий.

DevOps / SRE:

Настроить lint и CI-пайплайн с helm lint и helm package.
Внедрить репозиторий чарта и политику версий.
Настроить мониторинг релизов и алерты на failed deployments.

QA/Tester:

Проверить smoke-тесты после deploy в staging.
Использовать helm test для job-based тестов чарта.

Decision flow: Helm или Kustomize (Mermaid)

flowchart TD
  A[Нужно ли параметризовать манифесты?] -->|Да| B[Helm]
  A -->|Нет| C[Kustomize]
  B --> D{Много окружений и зависимости?}
  D -->|Да| E[Helm + Charts/Repo]
  D -->|Нет| F[Helm локально]
  C --> G{Требуется простой overlay?}
  G -->|Да| H[Kustomize в GitOps]
  G -->|Нет| I[Чистый YAML в Git]

Критерии приёмки

Чарт проходит helm lint без ошибок.
helm template генерирует валидные Kubernetes-манифесты (проверка через kubectl apply --dry-run=server).
Параметры конфигурации задокументированы в README и values.yaml.
Секреты не хранятся в открытом виде в репозитории.
CI выполняет пакетирование и публикацию чарта при успешных проверках.

Контрольный список при публикации чарта

Обновлён Chart.yaml.version
Выполнен helm lint
Добавлены NOTES.txt с инструкциями
Добавлены тесты в папку tests
Документация по values.yaml

Полезные команды (чек-лист)

helm create
helm lint ./chart
helm template ./chart -f values.yaml
helm install ./chart -f values.prod.yaml
helm upgrade ./chart -f values.prod.yaml –atomic –wait
helm uninstall
helm package ./chart
helm repo index ./ –url https://charts.example.com/

Частые сценарии и тестовые кейсы

Smoke-test после deploy: проверить, что Pod в статусе Running и сервис отвечает на health-check.
Обновление образа: увеличить appVersion и chart.version, провести staged deploy.
Откат релиза: вызвать helm rollback и убедиться, что приложение вернулось в рабочее состояние.

Локальные рекомендации и совместимость

Helm v3 и выше не использует Tiller, упрощая безопасность и интеграцию.
Следите за совместимостью API Kubernetes и используемых манифестов (apps/v1 vs extensions/v1beta1).

Краткое резюме

Helm помогает пакетизировать и параметризовать Kubernetes-приложения, делая развертывание, обновление и откат управляемыми и автоматизируемыми. Начните с helm create, изучите структуру чарта (Chart.yaml, values.yaml, templates) и обязательно интегрируйте linting и тестирование в CI/CD. Взвешивайте альтернативы (Kustomize, GitOps) в зависимости от простоты и требований к настройке.

Важно: Helm упрощает работу с конфигурациями, но при этом требует дисциплины в управлении секретами, версиями и тестами.

Если вы хотите, я могу подготовить пример полного чарта (архив) с README, tests и конфигурацией CI для GitHub Actions или GitLab CI.

Как начать писать Helm-чарты для приложений Kubernetes