Release Storage Architecture

Release Storage Architecture defines how Helm manages and stores release information and metadata for Kubernetes applications. It is a critical component of Helm's operational model, providing a persistent record of the state of deployed charts, enabling release lifecycle management, rollback, upgrades, and auditability.

Storage Backends

Helm supports multiple storage backends to persist release data. These storage backends abstract the underlying persistence layer, allowing Helm to save and retrieve releases consistently.

ConfigMaps

ConfigMaps are Kubernetes resources used to store non-confidential configuration data. When using ConfigMaps for release storage, Helm creates a ConfigMap per release, storing the release metadata and manifest data encoded in base64. This method is suitable for clusters where ConfigMaps are available and provides easy access to release data via native Kubernetes tooling.

Secrets

Secrets work similarly to ConfigMaps but are designed for storing sensitive data. Helm encodes release information in Secrets, offering better security by leveraging Kubernetes secrets encryption and restricted access controls. This is the default and recommended storage backend for Helm releases to protect release data from unauthorized exposure.

Memory (Driver)

The memory driver stores release data only in the running Helm client’s memory. It is ephemeral and used primarily for testing or transient operations, as no persistent state is maintained across Helm client restarts.

Other Drivers

Helm supports pluggable storage drivers, allowing extension or customization of release storage. This may include external databases or custom Kubernetes resources, but these are less common and require additional configuration.

Release Data Structure

Each Helm release stored in the backend contains structured data critical to managing the release lifecycle.

Release Metadata

Includes release name, namespace, chart version, app version, status (deployed, failed, superseded, etc.), and timestamps for creation and last update. This metadata provides the contextual information needed for release management and auditing.

Manifest Data

The complete Kubernetes manifest generated from the Helm chart templates combined with the values used during deployment. This allows Helm to know exactly what resources were created or modified.

Hooks and Notes

Information about lifecycle hooks (pre-install, post-install, pre-delete, etc.) and release notes are also stored to enable Helm to properly manage hook execution and provide user feedback.

Versioning and History

Each release storage entry is versioned. When a release is upgraded or rolled back, Helm creates a new version record, preserving history. This facilitates rollback to previous states and audit trail creation.

Storage Architecture Workflow

Creation and Update

When Helm installs or upgrades a release, it packages the release data and persists it to the configured storage backend. If the backend is ConfigMap or Secret, Helm creates or updates the corresponding Kubernetes resource with the release data.

Retrieval

To perform operations such as status checks, rollbacks, or upgrades, Helm retrieves the release data from the storage backend, decodes it, and reconstructs the release state.

Deletion

Upon release deletion, Helm removes the stored release metadata from the backend. In Kubernetes backends, this corresponds to deleting the associated ConfigMap or Secret.

Data Encoding and Compression

To efficiently store complex release data, Helm serializes release objects into protobuf or JSON, then compresses and base64 encodes them before saving in the backend resource. This reduces size and ensures data integrity during storage.

Access Control and Security

When using Kubernetes Secrets as a storage backend, Helm leverages Kubernetes RBAC policies to restrict access to release data. This prevents unauthorized users from viewing sensitive information contained in release manifests, such as passwords or tokens.

High Availability and Scalability Considerations

Since release data is stored in Kubernetes resources, it benefits from the cluster’s etcd high availability and backup mechanisms. However, large numbers of releases or large manifest sizes can impact cluster resource usage. Therefore, best practices recommend pruning old releases and optimizing chart manifests.

Visualization of Release Storage Architecture

Summary

The Release Storage Architecture in Helm is essential for maintaining the state and history of application deployments. It abstracts the persistence of release information into configurable backends, predominantly Kubernetes Secrets or ConfigMaps, ensuring data integrity, security, and accessibility. Its design enables Helm to provide robust lifecycle management features such as upgrades, rollbacks, and audits, all while integrating seamlessly with Kubernetes native resources and security models.