With the native Helm installation, you can exercise more control over chart deployment using Helm hooks and weights. In the native Helm installation workflow, the app manager deploys the app's v3 Helm charts with a
helm install command. This means that Helm owns the installation and lifecycle management of the chart resources. For new applications, native Helm is the preferred method because it supports more Helm features, such as hook and weights.
Migrating existing installations to the native Helm workflow is not supported. However, new Helm charts within an existing application can use the native Helm workflow and the features that come with it.
Native Helm Limitations
The native Helm chart support has the following limitations:
- Only available for Helm V3.
- Only supported for new installations.
- Not supported on existing charts deployed on existing applications.
- Migrating existing applications to the native Helm implementation is not supported. To deliver applications using the native Helm workflow, promote releases to a new channel for new customer installations.
- The test hook is not supported.
- Hook weights below -9999. All hook weights must be set to a value above -9999 to ensure the Replicated image pull secret is deployed before any resources are pulled.
- Not supported with the GitOps workflows.
- The name specified in the HelmChart CRD must be an exact match to the actual Helm Chart name that is provided to Replicated; failure to do this will result in errored installations.
Helm Hooks and Weights
Native Helm hooks and weights enable more control over when resources are deployed. This is useful if you want to bundle actions as part of a release. For example, you can build in a database backup as part of the upgrade process while ensuring that the backup occurs prior to upgrading the rest of the resources. The Helm weights provide even more control by governing the order of operations within each hook.
The following hooks are supported:
- pre-install - executes after resources are rendered but before any resources are installed.
- post-install - executes after resources are installed.
- pre-upgrade - executes after resources are rendered but before any resources are upgraded.
- post-upgrade - executes after resources are upgraded.
The following hooks may be used but no actions will be taken by Replicated:
- pre-rollback - executes after resources are rendered but before any resources are rolled back.
- post-rollback - executes after resources are rolled back.
- pre-delete - executes before any resources are deleted.
- post-delete - executes after resources are deleted.
For more information about Helm hooks and weights, see the Helm docs.
Enabling and Using Native Helm Charts
To leverage this option, set
useHelmInstall: true in the
HelmChart CRD. Then promote these changes to a channel and install new instances of the application with the native Helm installation. For any existing installations of the application, you can update these in the Replicated admin console or using the kots CLI. After they are updated, any new Helm charts added to the application are deployed with the native Helm installation.
For more information about adding charts to applications, see optional charts and the Helm docs. For information on ordering the Helm chart installations, seeDefining Installation Order for Native Helm Charts.
This is a chart level flag that is only supported for new charts. Modifying existing charts in existing applications is not supported.