Где Helm 3 хранит информацию о релизах внутри кластера Kubernetes?

Helm 3 по умолчанию хранит состояние релизов (историю, конфигурацию values, метаданные) в виде Secrets (тип helm.sh/release.v1) в том же namespace Kubernetes, куда был установлен релиз.

Как это выглядит на практике:

1. После установки релиза my-app в namespace production Helm создает секрет с именем sh.helm.release.v1.my-app.v1.
2. Этот секрет содержит закодированную в gzip и base64 информацию о релизе.
3. При обновлении до версии 2 создается новый секрет sh.helm.release.v1.my-app.v2, а предыдущий помечается меткой status: superseded.

Как проверить и работать с этим хранилищем:

# Показать все секреты-релизы Helm в namespace 'default'
kubectl get secrets -n default -l "owner=helm"

# Посмотреть детали конкретного релиза (данные в секрете закодированы)
kubectl get secret sh.helm.release.v1.my-app.v1 -n default -o jsonpath='{.data.release}' | base64 -d | base64 -d | gzip -d
# (Команда декодирует цепочку: base64 -> base64 -> gzip)

# Удалить все релизы Helm в namespace (ОПАСНО! Удалит историю)
kubectl delete secret -n default -l owner=helm

Важные технические детали из опыта:

• Драйвер хранилища: Можно заставить Helm 3 использовать ConfigMaps вместо Secrets, задав переменную окружения HELM_DRIVER=configmap. Но это менее безопасно, так как конфигмапы по умолчанию не шифруются. Я всегда оставляю Secrets как драйвер по умолчанию.
• Безопасность: Секреты Helm не шифруются "из коробки". Если в кластере включен Encryption at Rest для Secrets API, то они будут зашифрованы на уровне etcd, что является лучшей практикой.
• Проблема: Основной риск — случайное удаление этих секретов командой kubectl delete secret --all. Это приведет к тому, что Helm "забудет" о релизах, хотя сами ресурсы в кластере останутся. Восстановить связь будет сложно. Поэтому в production я всегда ограничиваю права на удаление ресурсов с меткой owner=helm.