Где Helm хранит свои данные о релизах в кластере Kubernetes?

Место хранения данных о релизах Helm

Helm хранит свои данные о релизах напрямую внутри кластера Kubernetes, используя его собственные механизмы хранения, а не во внешней базе данных или файловой системе. Это один из ключевых принципов архитектуры Helm, начиная с третьей версии (Helm 3), который обеспечивает тесную интеграцию с экосистемой Kubernetes.

Хранилище: Secrets или ConfigMaps (исторически)

В зависимости от используемого бэкенда (драйвера хранилища) и версии Helm, данные релиза записываются в один из двух типов ресурсов Kubernetes:

• Основной и рекомендуемый способ (Helm 3 по умолчанию): Secret.

    *   Каждый установленный или обновлённый релиз представлен в кластере в виде отдельного объекта `Secret`.
    *   Эти секреты имеют специальные метки, идентифицирующие их как принадлежащие Helm.
    *   Данные внутри секрета (в поле `data.release`) хранятся в **зашифрованном (base64) и сжатом (gzip) формате**.

• Исторический способ (Helm 2 и Helm 3 с драйвером configmap): ConfigMap.

    *   Helm 2 использовал ConfigMaps в пространстве имён `kube-system` для хранения истории релизов Tiller.
    *   В Helm 3 этот драйвер (`secret`, `configmap`) можно выбрать, но `secret` является значением по умолчанию и предпочтительным из соображений безопасности, так как содержимое зашифровано (base64), что обеспечивает базовый уровень обфускации данных, хотя и не является полноценным шифрованием.

Расположение и идентификация

По умолчанию объекты хранилища создаются в том же пространстве имён (Namespace), где был развёрнут сам релиз. Это важное отличие от Helm 2, где Tiller хранил всё централизованно. Каждый объект (Secret или ConfigMap), относящийся к релизу, содержит набор идентифицирующих меток:

# Пример Secret, созданного Helm 3
apiVersion: v1
kind: Secret
metadata:
  name: sh.helm.release.v1.my-awesome-app.v1 # Шаблон имени: sh.helm.release.v1.<release_name>.v<revision>
  namespace: default
  labels:
    owner: helm
    status: deployed
    version: "1"
type: helm.sh/release.v1
data:
  release: <gzipped, base64-encoded data of the release> # Данные релиза в сжатом и кодированном виде

Ключевые метки:

• owner: helm – указывает, что объект управляется Helm.
• status: deployed, superseded, failed и др. – показывает текущий статус этой конкретной ревизии релиза.
• version – номер ревизии.

Что именно хранится внутри?

Закодированные данные внутри поля release – это полное состояние релиза в формате protobuf (ранее – JSON или gob). Они включают в себя:

• Метаданные релиза: имя, версия (ревизия), пространство имён, статус, временные метки.
• Chart: полное определение использованного Helm Chart (включая значения values.yaml).
• Манифесты: сгенерированные Kubernetes-манифесты, которые были применены к кластеру в данной ревизии.
• История и хуки: информация о предыдущих версиях и хуках (hooks) релиза.

Практическая работа с хранилищем Helm

1. Просмотр релизов из CLI:

   helm list -n <namespace>
   

    Эта команда читает и декодирует соответствующие Secrets/ConfigMaps в указанном пространстве имён.

1. Просмотр "сырых" объектов хранилища через kubectl:

   # Показать все Secrets, управляемые 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 | gzip -d
   # (Вывод будет в бинарном protobuf формате)
   

2. Важные следствия архитектуры:

    *   **Безопасность доступа**: Для управления релизом через Helm или для прямого просмотра его истории пользователю необходимы соответствующие права RBAC на чтение/запись Secrets (или ConfigMaps) в целевом пространстве имён.
    *   **Зависимость от кластера**: История релиза привязана к кластеру. Удаление этих объектов из кластера равносильно потере истории для Helm. Команда `helm uninstall` с флагом `--keep-history` удаляет только ресурсы релиза, но оставляет объект хранилища (Secret) для возможного отката.
    *   **Миграция и бэкап**: Для переноса состояния Helm между кластерами необходимо переносить сами объекты хранилища. Эту задачу решают специализированные инструменты, например, **helm-secrets-plugin** или скрипты, работающие напрямую с kubectl.

Сравнение: Helm 2 vs Helm 3

Заключение: Helm 3 хранит данные о релизах (их историю, конфигурацию и манифесты) в виде специально помеченных объектов Secret (предпочтительно) или ConfigMap непосредственно в целевом пространстве имён кластера Kubernetes. Это решение устранило необходимость в компоненте Tiller, упростило модель безопасности и сделало состояние менеджера пакетов неотъемлемой частью состояния самого кластера.