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

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

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
    • 

  • чарт не использует config:reseedOnUpgrade
    • 
source:
  • чарт git:не reseedOnUpgrade:использует falsekubectl patch

Илии аналогичныйне параметртребует RBAC для local-источника.

auto-sync dynamic config
  • если меняется только dynamic config, а не шаблон пода workload, сам upgrade не должен пересоздавать под только из-за этой синхронизации

    • reseedOnUpgrade=false

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

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

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

    reseedOnUpgrade=true

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

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

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

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

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

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

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

    helm status blitz -n blitz
kubectl get pods,svc,ingress,pvc -n blitz
kubectl get 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-процедуру короткой и воспроизводимой
    Наверх