Support for Helm Releases
Learn about backup and restore of Helm Releases with Trilio for Kubernetes
Cloud-Native Applications
Deploying and managing cloud-native applications can be approached in a myriad of ways, this is why one of the promises of Trilio is to remain adaptive and flexible to the needs of its customers. While there are several popular methods of managing objects in a Kubernetes cluster, such as labels, namespaces, operators, and Kustomize, Helm has arguably become the standard for packaging, installation, and management of cloud-native application lifecycles.
While all backup and recovery solutions in the market today commonly support label and namespace-based applications, Trilio knows that supporting Helm and Kubernetes operator-based applications is equally if not more important. These generic backup methods, such as label-based and namespace-based, can only offer a limited ability to backup and restore Helm-based or Kubernetes Operator-based applications.
Backup and recovery solutions must strive to support applications no matter how they are designed and deployed. Users should not be forced to alter their applications or live with limited recoverability when a significant down-time event occurs. Any thing short of restoring the application in its entirety will cause severe disruption to business continuity.
Cloud-Native Backup and Restore for Helm
Helm can build, install upgrade and delete cloud-native applications.
This enables the user to accomplish the following tasks:
Customize their application while restoring to a target cluster
Manage multiple application releases in the one or many namespaces.
Rollback application releases to previous revisions
Handle upgrade to new application releases
Generic approaches like the label or namespace-based backup scheme only backup a collection of resources but they lose sight of what makes a Helm managed application so useful to the end user.
Other approaches to protecting Helm-based applications have limited capability to restore such backups and may suffer unforeseen consequences upon the user, including the disruption of production applications by not having the flexibility to restore to any arbitrary cluster and/or namespace.
Trilio enables the recovery of your running applications like it never even happened. Trilio restores from your backup target, directly replacing the application as though the applications life cycle had never been interrupted. Trilio for Kubernetes supports native Helm chart captures and restores to make this possible. With Trilio for Kubernetes, users have total flexibility to restore and transform their critical application data during disaster recovery.
Trilio enables Helm users to:
Customize the application during a restore operation, allowing your team to make critical adjustments to the application during a disaster recovery situation
Restore to any namespace
Preserve the Helm release history so that the application can be rolled back, upgraded, etc as allowed by Helm tooling.
Helm and Trilio Key Concepts
To take full advantage of Trilio's support for Helm releases, users should understand a few key Helm concepts as they relate to Trilio.
Helm Storage Backend:
Helm's persistent store for installed Helm chart, which may include helm templates, values, hooks, manifests, secrets, dependency information, and config maps. The Helm storage backend only includes the main chart templates and not any subcharts templates.
Helm SubCharts:
A subchart is a term used in Helm charts to refer to a chart that is included as a dependency within another chart, which is itself known as the parent chart. Trilio parses the Charts.yaml and reads the subchart dependencies list. It then fetches the dependency charts from their repositories and stores them on the backup target.
Helm Umbrella Charts
Helm charts can incorporate other charts, commonly known as subcharts, through their dependencies section. If a chart is designed to combine multiple subcharts or services that are related, typically to create a complete application or deployment, it is known as an umbrella chart. Trilio may change the release name or apply transformations during a restore that will require rendering the templates again, so it is important to correctly define dependencies. More information about Helm charts can be found here.
Helm Release Names:
Helm allows installation of multiple copies of the same application with different release names in the same namespace. If Trilio restores with the same release name, it cannot install the application in the same namespace because the new application resources will conflict with the existing application resources. Trilio cannot restore backups in a different namespace if the application contains a cluster scope resource. Even if the Trilio ignored these errors, removing an instance of the application will remove the cluster scope resource object and render the other application instances useless.
Trilio provides a comprehensive backup and recovery of helm applications by providing options to rename a release or apply transformations which allow for customization of the application so that resources are not in conflict with each other.
Best Practices for Helm and Subchart Dependencies
Helm charts can have dependencies on other charts that are specified as subcharts.
Trilio for Kubernetes makes every effort to protect your Helm charts even when they don't follow recommend best practices however, when a chart introduces unresolvable subchart dependancies it can limit Trilio's flexibility during a restore. Therefore, in some situations the restore is limited to the original namespace and restore transformations are not available.
For more information about Helm Chart best practices, see the official Helm documentation.
Trilio Support for Helm Chart Table
| # | Scenario | Trilio Protected? | Resolution Needed? | Notes |
|---|---|---|---|---|
1 | No subchart dependencies | Yes! | None | None of the complexity of nested dependencies |
2 | Well defined subchart dependencies | Yes! | None | Trilio can handle any level of well defined, Helm umbrella charts |
3 | Broken subchart dependencies | Yes! 1. Limited to same namespace 2. No transformations | 1. Provide access to the needed chart repository 2. Define subchart dependencies in Chart.yaml | Does Not adhere to best practice and limits restore options |
Trilio Support for Helm Chart Scenario Overview
1. Helm Charts without Subchart Dependencies
The Helm chart, including templates and values, is kept in the helm storage backend.
The Trilio backup process saves the helm chart to the configured backup target along with your application data.
The restore operation reads the helm chart from the backup target and renders it with a new release name and namespace.
The restore operation will also apply any configured transformations and executes any configured hooks.
With a more generic label-based backup method, the user cannot modify the release names or change the namespace. Additionally, a less flexible solution cannot utilize any transformations or hooks to customize the restoration. Trilio provides the flexibility to take control of your backup data and restore it how and where you need it.
2. Helm Charts with Well-Defined Subchart Dependencies
During backup operation, Trilio is able to read the subchart dependencies as they are defined in the Chart.yaml file of the parent chart and store them in the backup target. We assume a well-formed Helm chart has its subcharts configured and accessible to the cluster resources.
Trilio's restore function will render templates from the main chart and subcharts on the backup target into a new release name.
A different namespace can be chosen or a transformation can be used to customize the application.
Any applicable transformations are applied and any registered hooks are invoked.
Trilio's backup and restore process can manage any level of nested subcharts in a well-defined umbrella Helm chart.
3. Helm Charts With Broken Subchart Dependencies
Trilio can only render the parent chart templates from the Helm Storage Backend and must rely on defined dependencies for any subcharts.
The dependencies should be correctly defined in the Chart.yaml file of the user provided parent chart.
If the subchart dependencies are broken in anyway, restores to different namespaces and transformations are not possible.
Restores to the same namespace from an existing backup will still complete successfully.
Plan accordingly to ensure all Kubernetes resources have access to the required Helm subcharts, and that all subchart dependencies are well defined.
For example, the dependent subcharts must be defined and mentioned in the dependencies section of the Chart.yaml file or requirements.yaml file as shown below:
If subcharts are bundled together with the main chart in the charts directory and are not defined in the Chart.yaml file, running helm dep list against the helm chart will provide warnings if there are missing dependencies.
