Перейти к основному контенту

Обновление и откат

Helm делает обновление Blitz IDP достаточно прямолинейным, но в продакшен среде важно заранее понимать, что именно меняется в релизе, каков статус синхронизации динамичных конфигов и как безопасно откатиться к предыдущей версии.

Базовый порядок обновления

Перед обновлением рекомендуется:

  • сохранить изменённый values.yaml
  • проверить шаблоны через helm template
  • проверить chart через helm lint
  • зафиксировать текущую ревизию релиза

Команды для проверки:

helm history blitz -n blitz
helm template blitz ./helm -n blitz -f values-prod.yaml
helm lint ./helm -f values-prod.yaml

Команда обновления:

helm upgrade blitz ./helm -n blitz -f values-prod.yaml

Проверки перед обновлением

Перед helm upgrade убедитесь:

  • все поды текущего релиза в состоянии Ready
  • нет незавершённых Job
  • понятен ожидаемый состав изменений
  • база данных доступна
  • Vault и ingress-контроллер находятся в рабочем состоянии

Если используется PersistentVolumeClaim, отдельно проверьте состояние тома.

Особенности обновления при config.readOnly=false

В режиме динамической конфигурации init-conf запускается при каждом helm upgrade.

Текущее поведение такое:

  • job вычисляет отпечаток динамической конфигурации
  • если отпечаток не изменился, содержимое PVC не переписывается, обновляются только state-файлы
  • если отпечаток изменился, управляемые каталоги синхронизируются в PVC in-place
  • чарт не использует reseedOnUpgrade
  • чарт не использует kubectl patch и не требует RBAC для auto-sync dynamic config
  • если меняется только dynamic config, а не шаблон пода workload, сам upgrade не должен пересоздавать под только из-за этой синхронизации

reseedOnUpgrade=false

Это более осторожный режим. Обновление Helm не будет автоматически повторно публиковать конфигурацию в PersistentVolumeClaim.

Подходит, если:

  • нужно разделить обновление чарта и обновление конфигурации
  • вы хотите избежать неожиданных изменений файлов в runtime

reseedOnUpgrade=true

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

Подходит, если:

  • конфигурация меняется вместе с релизом
  • порядок поставки строго контролируется
  • команда понимает последствия повторной инициализации

Проверки после обновления

Сразу после helm upgrade проверьте:

  • статус Helm-релиза
  • состояние всех подов
  • наличие ошибок в логах
  • состояние Ingress
  • результат init-conf: noop или published
  • доступность внешнего URL

Полезные команды:

helm status blitz -n blitz
kubectl get pods,svc,ingress,pvc,jobs -n blitz

Выполнение отката

Сначала узнайте доступные ревизии:

helm history blitz -n blitz

Затем выполните откат:

helm rollback blitz 3 -n blitz

Здесь 3 — номер ревизии, к которой нужно вернуться.

После rollback обязательно проверьте:

  • состояние подов
  • readiness и health endpoint
  • состояние PersistentVolumeClaim, если используется RW-режим
  • корректность опубликованной конфигурации
  • доступность секретов и Ingress

Риски при обновлении

Смена режима конфигурации

Переход между:

  • config.readOnly=true
  • config.readOnly=false

нужно планировать отдельно. Это влияет на:

  • наличие PersistentVolumeClaim
  • способ поставки конфигурации
  • порядок эксплуатации
  • процедуру восстановления

Рекомендуем заранее выбрать фиксированный режим конфигурации и не изменять его.

Изменение состава модулей

Включение или выключение panel, ldapMfa, standby-режима console и других опций меняет состав ресурсов в кластере. После такого обновления нужно дополнительно проверить маршрутизацию, секреты и готовность новых подов.

Изменение секретов и Vault

Если одновременно обновляются:

  • путь в Vault
  • AppRole
  • параметры TLS до Vault

то риск регрессии высокий, такие изменения лучше проверить поэтапно.

Практические рекомендации

  • обновляйте Helm-релиз только из версионированных values-файлов
  • не совмещайте крупные изменения конфигурации и инфраструктуры без необходимости
  • сначала проверяйте шаблоны, затем обновляйте релиз
  • в RW-режиме дополнительно проверяйте логи init-conf и итоговый отпечаток после upgrade
  • сохраняйте rollback-процедуру короткой и воспроизводимой
Наверх