Release Upgrades

Release Upgrades refer to the process of updating an existing Helm release to a new version of a chart or a new configuration while preserving the integrity and stability of the deployed application. This process involves applying changes to the release’s resources in Kubernetes by upgrading the chart templates, values, and configurations without requiring manual intervention on the cluster resources. Release upgrades are fundamental for managing application lifecycle, delivering new features, bug fixes, and configuration improvements in a controlled and repeatable manner.

Upgrade Principles

Immutable Infrastructure and Declarative Updates

Helm relies on Kubernetes’ declarative model, where the desired state is defined through manifests. Upgrade operations replace the current release state with a new desired state based on updated charts and values. Each upgrade creates a new revision of the release, enabling rollback capabilities.

Incremental and Atomic Changes

Upgrades apply incremental changes using Kubernetes API calls (e.g., kubectl apply) to modify resources incrementally. Helm attempts to perform upgrades atomically, meaning either all changes succeed or none are applied. This reduces the risk of partially applied upgrades that could destabilize the application.

Versioning and Revision History

Each release upgrade increments the release revision number, maintaining a history of changes. This revision history allows administrators to roll back to a previous stable release if the upgrade introduces issues.

Upgrade Values and Configuration Reuse

Values Overrides Merging

When upgrading a release, Helm merges values provided during the upgrade with the existing release values and the chart’s default values. This merging ensures that user customizations from previous installations persist unless explicitly overridden.

Using --reuse-values Flag

The --reuse-values option instructs Helm to reuse the last release’s values instead of the chart defaults. This is particularly useful when upgrading the chart version but wanting to keep current configuration intact.

Example:

helm upgrade myrelease mychart --reuse-values

Partial Value Overrides

Users can supply new or modified values files or inline --set parameters during upgrade to selectively override specific settings while preserving others from the current configuration.

Example:

helm upgrade myrelease mychart --set image.tag=v2.0.1

Handling Deprecated or Removed Values

Upgrades to new chart versions may deprecate or remove certain values. Helm does not automatically reconcile such changes, so users must review release notes and adjust values accordingly to prevent configuration drift or errors.

Upgrade Strategies and Best Practices

Canary and Blue-Green Deployments

Although Helm upgrades apply changes in-place, orchestrating canary or blue-green deployment strategies can be achieved by managing multiple releases or namespaces, allowing validation of new versions before full cutover.

Dry Runs and Debugging

Using the --dry-run flag simulates the upgrade process without applying changes, enabling validation of manifests and configuration correctness.

Example:

helm upgrade myrelease mychart --dry-run --debug

Rollbacks and Failure Handling

If an upgrade fails or causes issues, Helm provides rollback functionality to restore the previous release revision seamlessly.

Example:

helm rollback myrelease 2

Where 2 is the revision number to revert to.

Managing Dependencies and Subcharts

Upgrades must consider dependencies defined in Chart.yaml. Helm manages dependency upgrades by updating subcharts accordingly. Users should run helm dependency update prior to upgrading to ensure dependencies are current.

Technical Workflow of a Release Upgrade

1. Chart and Value Preparation: The user prepares the new chart version and modified values for the upgrade.
2. Validation: Helm validates the provided chart and values, performing template rendering.
3. Manifest Generation: Helm renders Kubernetes manifests based on the chart templates and merged values.
4. Resource Diffing: Helm compares the new manifests with the currently deployed resources to determine the necessary changes.
5. Kubernetes API Calls: Helm applies the changes using Kubernetes APIs to create, update, or delete resources.
6. Release Record Update: Helm updates the release metadata, incrementing the revision and storing the new manifest and values.
7. Post-Upgrade Hooks: Helm executes lifecycle hooks like post-upgrade to perform additional tasks if defined.
8. Status Checks: Helm monitors the status of the release resources to ensure successful deployment.
9. Rollback Capability: If failures occur, Helm can revert to the previous revision automatically or manually.

Considerations for Complex Upgrades

Stateful Applications

Upgrades involving StatefulSets or databases require careful handling of data migrations and state preservation. Helm upgrades do not inherently manage data schema changes, so additional tooling or manual steps may be necessary.

Custom Resources and CRDs

When upgrading charts that include CustomResourceDefinitions (CRDs), Helm treats CRDs specially; it installs or upgrades CRDs before other resources but does not upgrade CRDs automatically on subsequent upgrades. Users must manage CRD upgrades separately.

Hooks and Lifecycle Management

Helm supports hooks (pre-upgrade, post-upgrade, pre-rollback, etc.) which can run jobs or scripts during upgrade phases. These hooks allow complex upgrade logic such as backups, migrations, or notifications.

Summary of Helm Upgrade Commands

Release upgrades are a critical aspect of Helm’s functionality, enabling controlled and repeatable deployment of application changes over time, leveraging Kubernetes’ declarative model, and providing mechanisms for configuration reuse, rollback, and lifecycle management.