Helm-чарты для Kubernetes: пошаговый гайд по деплою

Введение

Helm chart для Kubernetes — это стандартный способ упаковки и деплоя приложений в кластер. Вместо того чтобы вручную писать десятки YAML-манифестов для каждого окружения, вы описываете приложение один раз в виде чарта и разворачиваете его одной командой.

Helm выступает пакетным менеджером для Kubernetes, как npm для Node.js или pip для Python. Он берет на себя шаблонизацию манифестов, управление зависимостями и версионирование релизов. В этой статье разберем создание Helm chart с нуля и пройдем весь путь от инициализации до деплоя приложения в Kubernetes.

Структура Helm чарта и его компоненты

Создание Helm chart начинается с команды, которая генерирует базовую структуру:

# Создаем новый чарт для нашего приложения
helm create myapp

Команда создаст директорию со следующей структурой:

myapp/
  Chart.yaml          # Метаданные чарта
  values.yaml         # Параметры по умолчанию
  templates/          # Шаблоны манифестов
    deployment.yaml
    service.yaml
    ingress.yaml
    _helpers.tpl      # Вспомогательные шаблоны
    NOTES.txt         # Сообщение после установки
  charts/             # Зависимости (субчарты)

Файл Chart.yaml содержит метаданные чарта:

apiVersion: v2
name: myapp
description: Helm chart для деплоя веб-приложения
type: application
version: 0.1.0        # Версия чарта
appVersion: "1.0.0"   # Версия приложения

Поле version обновляется при каждом изменении чарта, а appVersion отражает версию самого приложения. Это разделение позволяет обновлять конфигурацию деплоя независимо от кода приложения.

Настройка values.yaml для параметризации деплоя

Файл values.yaml — это центральное место для настройки параметров чарта. Все значения из этого файла доступны в шаблонах через объект .Values:

# values.yaml — параметры по умолчанию
replicaCount: 2

image:
  repository: myregistry/myapp
  tag: "1.0.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 80
  targetPort: 3000

resources:
  limits:
    cpu: 500m
    memory: 256Mi
  requests:
    cpu: 100m
    memory: 128Mi

env:
  NODE_ENV: production
  LOG_LEVEL: info

ingress:
  enabled: true
  host: myapp.example.com

Для разных окружений создаются отдельные файлы значений. Например, values-staging.yaml переопределяет только нужные параметры:

# values-staging.yaml — переопределения для staging
replicaCount: 1

image:
  tag: "1.0.0-rc.1"

env:
  NODE_ENV: staging
  LOG_LEVEL: debug

ingress:
  host: staging.myapp.example.com

Как создать шаблоны deployment и service

Шаблоны в директории templates/ используют синтаксис Go templates. Файл deployment.yaml описывает основной ресурс:

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "myapp.fullname" . }}
  labels:
    {{- include "myapp.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "myapp.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "myapp.selectorLabels" . | nindent 8 }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - containerPort: {{ .Values.service.targetPort }}
          env:
            {{- range $key, $value := .Values.env }}
            - name: {{ $key }}
              value: {{ $value | quote }}
            {{- end }}
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

Шаблон service связывает pod с сетью кластера:

# templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: {{ include "myapp.fullname" . }}
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.service.targetPort }}
      protocol: TCP
  selector:
    {{- include "myapp.selectorLabels" . | nindent 4 }}

Обратите внимание на функцию include — она подставляет именованные шаблоны из _helpers.tpl, что избавляет от дублирования меток и имен.

Деплой приложения в Kubernetes с Helm

Перед установкой полезно проверить, какие манифесты сгенерирует Helm:

# Рендерим шаблоны без установки
helm template myapp ./myapp --values values-staging.yaml

Проверяем валидность чарта:

# Валидация чарта
helm lint ./myapp

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

# Первый деплой приложения
helm install myapp ./myapp \
  --namespace myapp-ns \
  --create-namespace \
  --values values-staging.yaml

Для обновления существующего релиза используйте helm upgrade:

# Обновление релиза с новыми параметрами
helm upgrade myapp ./myapp \
  --namespace myapp-ns \
  --values values-staging.yaml \
  --set image.tag="1.1.0"

Флаг --set позволяет переопределить отдельные значения без изменения файлов. Это удобно для CI/CD пайплайнов, где тег образа подставляется динамически.

Как откатить неудачный релиз

Helm хранит историю релизов, что позволяет быстро выполнить rollback:

# Просмотр истории релизов
helm history myapp --namespace myapp-ns

# Откат к предыдущей версии
helm rollback myapp 1 --namespace myapp-ns

Частые ошибки при работе с Helm

Первая ошибка — хардкод значений в шаблонах вместо использования values.yaml. Это лишает чарт гибкости и вынуждает менять шаблоны для каждого окружения.

Вторая проблема — отсутствие ресурсных лимитов. Без указания resources.limits и resources.requests планировщик Kubernetes не может корректно распределить pod по нодам кластера.

Третья ошибка — игнорирование команды helm lint перед деплоем. Линтер находит синтаксические ошибки в шаблонах до того, как они попадут в кластер.

Четвертая проблема — хранение секретов в values.yaml. Пароли и токены должны передаваться через Kubernetes Secrets или внешние системы управления секретами, а не храниться в репозитории.

Заключение

Helm chart для Kubernetes значительно упрощает деплой приложений, превращая набор YAML-манифестов в переиспользуемый пакет с параметризацией. Создание чарта с правильной структурой, гибким values.yaml и чистыми шаблонами позволяет разворачивать приложение в любом окружении одной командой helm install. Используйте helm lint и helm template для проверки перед деплоем, а helm rollback — для быстрого отката при проблемах.