Helm: чарты и values

Проблема: голый YAML дублируется, а у kubectl apply нет отмены

У обычного YAML Kubernetes две структурные дыры, как только ты гоняешь одно приложение больше чем в одном месте. Первая — дублирование: окружения отличаются горсткой значений — число реплик, тег образа, лимиты ресурсов, hostname, — но у YAML нет параметров, поэтому ты копируешь весь набор манифестов на окружение и держишь их в синхроне руками. Дрейф неизбежен. Вторая — нет единицы релиза: kubectl apply -f отправляет текущие файлы в кластер и забывает. Он не записывает «это версия 4 my-api», не умеет связать Deployment + Service + ConfigMap + Ingress в один атомарный объект и не знает понятия отката к предыдущей версии. Хочешь отменить — реконструируй старый YAML сам.

Helm — де-факто пакетный менеджер Kubernetes — закрывает обе дыры. Он вводит единицу упаковки (chart), механизм параметризации (values) и stateful версионированную единицу деплоя (release).

Chart — это пакет: templates + значения по умолчанию + метаданные

Chart — это директория (или упакованный .tgz) с фиксированной раскладкой. Три части, важные с первого дня:

my-api/
  Chart.yaml          # метаданные: name, version, appVersion, dependencies
  values.yaml         # значения по умолчанию (публичный API чарта)
  templates/
    deployment.yaml   # манифесты K8s, но с плейсхолдерами Go-template
    service.yaml
    _helpers.tpl      # переиспользуемые сниппеты шаблонов

templates/ держит обычные манифесты Kubernetes с плейсхолдерами Go-template, вбитыми в места, которые меняются. Helm рендерит эти шаблоны против дерева values, чтобы получить финальный плоский YAML, и шлёт его в кластер.

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-api
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    spec:
      containers:
        - name: api
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          resources:
            limits:
              memory: {{ .Values.resources.limits.memory }}

values.yaml поставляет значения по умолчанию — и заодно служит документированным публичным интерфейсом чарта:

# values.yaml (значения по умолчанию)
replicaCount: 1
image:
  repository: registry.example.com/my-api
  tag: dev
resources:
  limits:
    memory: 256Mi

Values переопределяют шаблоны под окружение

Один и тот же chart рендерит разные манифесты, потому что ты кормишь его разными values. Держишь по одному небольшому файлу на окружение и передаёшь его при install/upgrade через -f или переопределяешь отдельные ключи через --set. Приоритет слоистый: values.yaml чарта — база, каждый файл -f переопределяет её слева направо, а флаги --set бьют всё.

# values-prod.yaml — только то, что отличается от значений по умолчанию
replicaCount: 6
image:
  tag: "1.8.3"
resources:
  limits:
    memory: 1Gi

# один chart, три окружения — единственная разница в values
helm upgrade --install my-api ./my-api -f values-prod.yaml
helm upgrade --install my-api ./my-api -f values-staging.yaml --set image.tag=rc-42

Это несущая идея: values — это граница окружения. Шаблон кодирует форму твоего деплоя один раз; values несут факты, специфичные для окружения. Определение readiness-пробы ровно одно на сопровождение, и dev/staging/prod больше не могут разъехаться в частях, которые должны быть идентичны.

Releases: install, upgrade, rollback как одна версионированная единица

Когда ты helm install (или helm upgrade --install) chart, Helm создаёт именованный release и записывает пронумерованную ревизию ровно того, что задеплоил, храня её как Secret в кластере. Каждый helm upgrade поднимает номер ревизии. Поскольку Helm помнит каждую ревизию, helm rollback my-api 4 — это одна команда, которая заново применяет известно-хорошее прошлое состояние, — «отмена», которой у kubectl apply никогда не было. helm uninstall удаляет ресурсы всего release разом. Это превращает деплой из «кучи YAML, которую я впихнул в API-сервер» в атомарную, версионированную, обратимую транзакцию над именованным набором.

helm upgrade --install my-api ./my-api -f values-prod.yaml  # -> ревизия 5
helm history my-api                                         # все ревизии
helm rollback my-api 4                                      # атомарная отмена к рабочему состоянию

kubectl apply vs Helm, кратко

Шаринг и переиспользование: репозитории и subcharts

Зачем писать StatefulSet для Postgres с нуля, если production-grade чарты уже существуют, проверены на практике и несут разумные настройки по умолчанию? Именно здесь экосистема чартов окупается.

Чарты — распространяемые артефакты. Публичные chart-репозитории — самый известный Bitnami — публикуют production-grade чарты для готовой инфраструктуры (Postgres, Redis, nginx), так что тебе не надо писать руками stateful-set под базу. Можно и композировать: chart может объявить зависимости (subcharts) в Chart.yaml, а values родителя могут переопределить values сабчарта, так что зонтичный chart связывает твоё приложение с зависимостями как один release.

Заметки сеньора: никогда не апгрейдь вслепую

Две практики отделяют безопасный Helm-воркфлоу от опасного. Предпросмотр до применения. helm upgrade --dry-run рендерит манифесты, не трогая кластер; широко используемый плагин helm diff upgrade показывает точное изменение против живого release, так что ты видишь «это удалит PVC» до того, как это случится, а не после. Версионируй всё. Chart несёт две версии в Chart.yaml: version (собственная версия чарта, поднимай при любом изменении чарта) и appVersion (приложение, которое он поставляет). Относись к чартам как к коду — пинни версию чарта, которую используют твои окружения, и поднимай её осознанно. И помни про ловушку upgrade-vs-recreate: правка неизменяемого поля (spec у Job, clusterIP у Service, некоторые поля volume) не патчится на месте; upgrade падает или, в зависимости от ресурса, форсит пересоздание, которое может означать даунтайм. Читай diff, знай, какие поля неизменяемы, и планируй раскатку — helm rollback это твоя страховка, а не стратегия.