Guides
Kubernetes

Helm values: override без форка чарта

Как правильно переопределять values в Helm: values.yaml, --set, --set-file, --values. Иерархия приоритетов. Как не потер

#guide#kubernetes

Всем привет. Если вы управляете Helm-релизами в продакшене, то наверняка сталкивались с ситуацией, когда нужно подменить пару значений в чарте, но создавать и поддерживать собственный форк — непозволительная роскошь. Сегодня разберем, как правильно и надежно переопределять values, чтобы ваши конфигурации были управляемыми, воспроизводимыми и не терялись после helm upgrade.

Иерархия приоритетов: что побеждает

Первое правило — понимать порядок применения значений. Helm применяет их в следующем порядке (от низшего к высшему приоритету):

  1. Значения из values.yaml, встроенного в чарт.
  2. Файл values.yaml, указанный при установке (-f или --values).
  3. Файлы, переданные через --values (могут быть несколько, последний переопределяет предыдущие).
  4. Аргументы --set и --set-file из командной строки.
  5. Файл values.yaml из зависимого чарта (subchart), который переопределяет родительский.

Проще запомнить так: чем ближе к команде helm install/upgrade, тем выше приоритет. --set всегда бьет всё.

Практические методы переопределения

1. Файлы values.yaml — основа основ Создайте свой файл values-prod.yaml для каждого окружения. Это главный источник истины для конфигурации. Храните его в Git.

# values-prod.yaml
replicaCount: 5
image:
  tag: "v1.2.3-prod"
resources:
  limits:
    memory: 512Mi

Установка: helm install myapp -f values-prod.yaml ./chart

2. Аргумент –set — для быстрых экспериментов Идеален для отладки, но опасен для продакшена, так как легко теряется.

helm upgrade myapp ./chart --set replicaCount=3,image.tag=latest

3. –set-file — для многострочных значений Полезно для вставки сертификатов, конфигов или скриптов без экранирования.

echo "some complex script" > init.sql
helm upgrade myapp ./chart --set-file initScript=init.sql

4. Каскадирование файлов для слоистой конфигурации Можно разделить конфигурацию на базовую и окружение-специфичную.

# base.yaml - общие настройки
# prod.yaml - только отличия для прода
helm install myapp -f base.yaml -f prod.yaml ./chart

Как не потерять overrides при helm upgrade

Самая частая ошибка — запустить helm upgrade без повторного указания кастомных values. Helm не запоминает, какие файлы или --set использовались при install. Решение — всегда использовать -f с вашим файлом values или хранить конфигурацию в CI/CD-пайплайне. Никогда не полагайтесь на --set в ручных операциях.

Управление секретами: выносим за скобки

Никогда не храните секреты в values.yaml, даже зашифрованные. Используйте специализированные инструменты.

Вариант A: Sealed Secrets Создаете запечатанный секрет локально, в Git кладете только его. Чарт работает с обычным Secret, который создается оператором.

# Шаблон в чарте (templates/secret.yaml)
apiVersion: v1
kind: Secret
metadata:
  name: {{ .Release.Name }}-db-creds
data:
  password: {{ .Values.dbPassword | b64enc }}

А в вашем values-prod.yaml ссылаетесь на него через externalSecret или вообще оставляете пустым, если оператор сам внедряет секрет.

Вариант B: External Secrets Operator Золотой стандарт. В values указываете только ссылку на секрет из внешнего хранилища (AWS Secrets Manager, Vault). Сам чарт не содержит никаких чувствительных данных.

# values-prod.yaml
database:
  passwordSecretRef:
    name: "prod-db-password"
    key: "password"

Типичные грабли

  1. Смешивание методов без понимания приоритетов. Получается неконсистентная конфигурация, которая ведет себя по-разному в CI и локально.
  2. Использование --set для установки сложных объектов. Легко ошибиться в синтаксисе. Лучше добавить значение в файл values.yaml.
  3. Попытка переопределить значения subchart напрямую из родительского --set. Нужно использовать полный путь с префиксом имени subchart: --set subchartName.key=value.
  4. Игнорирование --reuse-values при upgrade. Если вы делаете helm upgrade --set newKey=value, все предыдущие --set сбросятся. Используйте --reuse-values, чтобы сохранить их, а затем применить новые.

Итог: ваша конфигурация должна быть идемпотентной. Запуск одного и того же helm upgrade -f values-env.yaml должен давать одинаковый результат всегда. Дисциплинированное использование файлов values, отказ от --set в продакшене и правильная работа с секретами через внешние системы — залог спокойной жизни.