Как вы производите обновление чартов в Helm

Стратегия обновления Helm-чартов в production-среде

Обновление Helm3-чартов — критически важный процесс в DevOps-практиках, который мы выстраиваем с учетом безопасности, надежности и минимального downtime. Вот наш многоуровневый подход:

1. Принципы и подготовка

Иммутабельность и версионирование — ключевые принципы. Мы НЕ правим установленные релизы (helm upgrade --set). Вместо этого:

• Все изменения вносятся в исходный код чарта в Git.
• Каждый чарт следует Semantic Versioning (SemVer). Изменения в Chart.yaml:

  apiVersion: v2
  name: my-app
  version: 1.2.3  # MAJOR.MINOR.PATCH
  appVersion: "v4.5.6"
  

Helm Dependency Management:

# Обновляем зависимости перед релизом
helm dependency update ./my-chart
helm dependency build ./my-chart

2. Процесс обновления: шаги и команды

Мы используем GitOps-подход с ArgoCD/Flux для production, но ручное обновление (для понимания) выглядит так:

1. Предварительные проверки:

   # Линтинг чарта
   helm lint ./my-chart
   
   # Проверка шаблонов (что сгенерируется)
   helm template my-release ./my-chart --values prod-values.yaml
   
   # Тестирование на staging (с dry-run)
   helm upgrade my-release ./my-chart \
     --namespace production \
     --values prod-values.yaml \
     --dry-run \
     --debug
   

2. Стратегия самого обновления:

   # Основная команда с критичными параметрами
   helm upgrade my-release ./my-chart \
     --namespace production \
     --values prod-values.yaml \
     --values secrets-encrypted.yaml \
     --atomic \           # Откат при неудаче
     --cleanup-on-fail \  # Очистка ресурсов при откате
     --timeout 10m \      # Таймаут операции
     --wait \             # Ждем readiness всех ресурсов
     --history-max 10     # Ограничиваем историю релизов
   

3. Пост-деплой проверки:

   # Статус релиза
   helm status my-release --namespace production
   
   # История для возможного отката
   helm history my-release --namespace production
   
   # Проверка развернутых ресурсов
   kubectl get all -l "app.kubernetes.io/instance=my-release" --namespace production
   

3. Продвинутые стратегии для production

Для минимизации downtime используем:

Blue-Green Deployment (через Helm):

# В values.yaml
deployment:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 0

Canary Releases:

# 1. Развертываем канареечную версию с 10% трафика
helm install my-app-canary ./my-chart \
  --namespace production \
  --set canary.enabled=true \
  --set canary.weight=10 \
  --set image.tag=v1.2.3

# 2. Постепенно увеличиваем вес, затем заменяем основной релиз

4. Интеграция в CI/CD Pipeline

Пример GitLab CI/CD stages для Helm:

stages:
  - lint
  - test
  - package
  - deploy

helm-package:
  stage: package
  script:
    - helm package ./chart --app-version $CI_COMMIT_TAG
    # Сохраняем .tgz в артефакты или репозиторий (ChartMuseum/Harbor)

helm-deploy:
  stage: deploy
  script:
    - helm upgrade --install $RELEASE_NAME ./chart \
        --namespace $NAMESPACE \
        --values values-$ENV.yaml \
        --atomic --wait --timeout 5m
  only:
    - main  # Только из main ветки

5. Безопасность и secret management

Никаких секретов в plain text! Используем:

• SOPS с Age/GPG для шифрования values-secrets.yaml
• Helm Secrets plugin для transparent расшифровки
• External Secrets Operator для синхронизации с Vault/AWS Secrets Manager

6. Откат (Rollback)

При необходимости:

# Просмотр истории
helm history my-release --namespace production

# Откат к конкретной ревизии
helm rollback my-release 3 --namespace production --wait

# Или полный переразверт предыдущей версии чарта
helm upgrade my-release ./my-chart \
  --version 1.2.2 \  # Конкретная версия чарта
  --values prod-values.yaml

7. Инструменты и лучшие практики

• Helm Diff Plugin — показ изменений перед применением:

  helm diff upgrade my-release ./my-chart --values prod-values.yaml
  

• Хранение чартов — в OCI registry (Harbor) или специализированном репозитории (ChartMuseum)
• Policy-валидация — с использованием Conftest/OPA Gatekeeper

Итог: Наш процесс — не просто helm upgrade, а комплексный CI/CD-пайплайн с автоматическим тестированием, строгим версионированием, безопасной работой с секретами и четкими стратегиями деплоя, что обеспечивает надежные обновления даже для самых критичных production-нагрузок. Каждое изменение чарта проходит через code review, линтинг, тестирование в staging-окружении и только затем применяется к production с возможностью мгновенного отката.