core code helper

Helm: шаблони, values і релізи без болю

Як упакувати застосунок у Helm-чарт, розділити налаштування для середовищ, перевіряти шаблони до деплою і відкочувати невдалі релізи.

0 імпортували Імпортувати собі

Коли маніфестів стає десяток, а середовищ — три, копіювання YAML з правкою кількох рядків перетворюється на джерело помилок. Helm — пакетний менеджер для Kubernetes: шаблони маніфестів + значення для кожного середовища + історія релізів з відкатом.

Структура чарту

helm create api
api/
  Chart.yaml            # назва, версія чарту, версія застосунку
  values.yaml           # значення за замовчуванням
  templates/
    deployment.yaml
    service.yaml
    hpa.yaml
    _helpers.tpl        # іменовані шаблони (мітки, імена)
    NOTES.txt           # підказка після встановлення

Шаблон і значення

# values.yaml
replicaCount: 2
image:
  repository: ghcr.io/acme/api
  tag: ""               # якщо порожньо — береться appVersion з Chart.yaml
resources:
  requests: { cpu: 100m, memory: 256Mi }
  limits: { memory: 384Mi }
env:
  LOG_LEVEL: info
# templates/deployment.yaml (фрагмент)
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: api
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
          resources:
            {{- toYaml .Values.resources | nindent 12 }}
          env:
            {{- range $name, $value := .Values.env }}
            - name: {{ $name }}
              value: {{ $value | quote }}
            {{- end }}
Порада

nindent і toYaml — найкорисніші функції Helm. Вони вставляють цілі блоки з правильним відступом. Більшість помилок «YAML parse error» — це неправильний відступ у шаблоні.

Значення для середовищ

# values-production.yaml — лише відмінності від values.yaml
replicaCount: 4
resources:
  requests: { cpu: 500m, memory: 512Mi }
  limits: { memory: 768Mi }
env:
  LOG_LEVEL: warn
helm upgrade --install api ./api \
  -n production --create-namespace \
  -f values-production.yaml \
  --set image.tag=1.4.2 \
  --atomic --timeout 5m
  • upgrade --install — встановити, якщо релізу ще немає, або оновити;
  • --atomic — якщо поди не стали готовими за --timeout, Helm автоматично відкотить реліз;
  • пізніші -f і --set перекривають попередні значення.

Перевірка до деплою

helm lint ./api -f values-production.yaml          # синтаксис і структура
helm template api ./api -f values-production.yaml  # зрендерити маніфести локально
helm upgrade api ./api -f values-production.yaml --dry-run=server   # перевірка API-сервером

Плагін helm-diff показує, що саме зміниться в кластері, — як terraform plan для Kubernetes:

helm diff upgrade api ./api -n production -f values-production.yaml --set image.tag=1.4.3

Історія і відкат

helm history api -n production
# REVISION  STATUS      CHART      APP VERSION  DESCRIPTION
# 7         superseded  api-0.9.0  1.4.1        Upgrade complete
# 8         deployed    api-0.9.1  1.4.2        Upgrade complete

helm rollback api 7 -n production
Увага

Helm зберігає історію релізів у Secrets у namespace релізу. Якщо хтось змінить ресурси вручну через kubectl edit, Helm про це не знатиме — і наступний upgrade може перезаписати ручні зміни або поводитися неочікувано. Усі зміни — лише через чарт.

Секрети

Не кладіть паролі у values.yaml у Git. Варіанти:

  • External Secrets Operator — секрети з Vault, AWS Secrets Manager тощо;
  • SOPS + helm-secrets — зашифровані файли значень у репозиторії;
  • створення Secret окремо, а в чарті — лише посилання на нього (existingSecret).

Залежності та бібліотечні чарти

# Chart.yaml
dependencies:
  - name: redis
    version: "~20.0.0"
    repository: oci://registry-1.docker.io/bitnamicharts
    condition: redis.enabled

Коли сервісів багато й чарти схожі, виносьте спільні шаблони в library chart — один раз описаний Deployment з пробами, ресурсами й мітками перевикористовується всіма.

Helm і GitOps

У зрілих командах helm upgrade руками не запускають. Argo CD або Flux стежать за репозиторієм і самі синхронізують кластер з описаним станом. Чарт і values-файли залишаються тими самими — змінюється лише те, хто натискає кнопку.

Що робить прапорець --atomic у helm upgrade?

Якщо реліз не став успішним за час --timeout (наприклад, нові поди не пройшли readiness), Helm автоматично виконає відкат до попередньої ревізії. Без нього кластер залишиться у напівоновленому стані з релізом у статусі failed.

Збережіть статтю собі

Увійдіть, щоб імпортувати її у власні нотатки, відмічати вивчене, ставити лайки й питати спільноту. Реєстрація безкоштовна: вхід через Google займає кілька секунд.

Увійти через Google Інші способи входу