Какие плюсы и минусы у команды `helm upgrade`?

Плюсы:

• Декларативность и идемпотентность: Команда helm upgrade --install приводит состояние релиза в кластере к состоянию, описанному в chart. Можно безопасно выполнять многократно.
• Гибкое управление конфигурацией: Возможность переопределять значения через --values, --set или --set-file позволяет использовать один chart для разных окружений (dev, staging, prod).
• Встроенные стратегии обновления: Поддержка hooks (pre-upgrade, post-upgrade) для выполнения миграций БД или других задач, связанных с деплоем.
• Простой откат: Команда helm rollback <RELEASE> <REVISION> быстро возвращает к предыдущей стабильной версии, что критично для CI/CD пайплайнов.
• Трехстороннее слияние: Helm пытается сохранить пользовательские изменения, сделанные kubectl edit, при обновлении, хотя это и требует осторожности.

Минусы:

• Сложность с отслеживаемостью изменений: По логам helm upgrade не всегда очевидно, какие именно ресурсы Kubernetes были изменены. Часто приходится дополнять вызовом kubectl diff (с плагином) или использовать helm template для предпросмотра.
• Проблемы с состоянием (stateful resources): Обновление chart'ов для StatefulSets или ресурсов с PersistentVolumeClaims требует особой осторожности и часто ручной настройки (helm upgrade --force может быть опасен).
• Зависимости (dependencies): Обновление родительского chart не всегда автоматически тянет за собой обновление зависимостей (helm dependency update нужно запускать отдельно).

Пример использования в пайплайне:

# Предпросмотр изменений (используя плагин diff)
helm diff upgrade my-app ./chart -f values/prod.yaml

# Непосредственно деплой с atomic-откатом при ошибке
helm upgrade --install my-app ./chart 
  -f values/prod.yaml 
  --namespace production 
  --atomic --timeout 5m 
  --set image.tag="${CI_COMMIT_SHA}"