Skip to main content

About Deploying with Helm

Helm is a popular package manager for Kubernetes applications. If your application is already packaged using Helm, you can use Replicated to more easily distribute and manage your application. Using Replicated to distribute applications packaged with Helm provides additional functionality not available through Helm, such as preflight checks, support bundles, a user interface for collecting user configuration values, support for using private images, and more.

Replicated supports delivering an enterprise application as Helm charts, or including Helm charts as components of an application. An application can use more than one Helm chart, and can use more than a single instance of any Helm chart.

To deploy a Helm chart, start by adding the Helm chart to a release in the Replicated vendor portal. For information about how to create a new release from an existing Helm chart, see Creating Releases with Helm Charts.

How Replicated Deploys Helm Charts​

When you distribute an application packaged with Helm, your customers can install and manage the application with the Replicated app manager or with the helm CLI.

Using the App Manager​

Users can install an application packaged with Helm charts using the app manager on an existing cluster or on a cluster provisioned by the Kubernetes installer. When installing with the app manager, users can either use the Replicated admin console UI or the kots CLI.

The app manager installs Helm charts using either the Native Helm or Replicated Helm deployment method. You specify the deployment method in the Replicated HelmChart custom resource manifest file with the useHelmInstall flag. For more information, see useHelmInstall in HelmChart.

The following describes the native Helm and Replicated Helm deployment methods:

  • Native Helm (Recommended): The app manager uses the Helm binary to install and manage the lifecycle of the chart resources that are part of the application. This is the preferred method because it supports more features of Helm, such as hooks and weights.

    For more information, see Native Helm in How the App Manager Processes Helm Charts. See also Creating Releases with Helm Charts.

    note

    Charts installed with Replicated Helm cannot be migrated to use native Helm. However, native Helm can always be used for charts that are newly added to a release, even if other charts in the release use Replicated Helm.

  • Replicated Helm: The app manager renders the Helm templates and deploys them as standard Kubernetes manifests using kubectl apply. The app manager manages the lifecycle of the resources.

    For more information, see Replicated Helm in How the App Manager Processes Helm Charts.

For limitations of the native Helm and Replicated Helm deployment methods, see Native Helm and Replicated Helm Limitations below.

Using the helm CLI (Beta)​

Users can install an application packaged with a Helm chart into an existing cluster using the helm CLI. When users install with the helm CLI directly, Helm, rather than the app manager, manages the lifecycle of the application.

Deploying an application with the helm CLI differs from the "native Helm" deployment method described above because, when users install with the helm CLI directly, they have access to all Helm functionality. Some enterprise users also prefer or require using the helm CLI because their existing CI/CD pipeline is already compatible with Helm charts. Similarly, enterprise users might have organizational policies that require using Helm to manage applications.

Users do not have access to certain Replicated features when they install and manage the application with the helm CLI directly. This is because the app manager does not manage the lifecycle of the application. For example, users must update the application using the helm upgrade command, rather than using the admin console UI or the kots CLI.

For more information about how to package an application so that users can install using the helm CLI, see Supporting helm CLI Installations (Beta).

Limitations​

This section lists the limitations for packaging an application with Helm charts.

There are different limitations depending on if your customers install and manage the application with the app manager, or if they use the helm CLI directly:

Native Helm and Replicated Helm Limitations​

The following limitations apply when using the app manager to install and manage Helm charts:

  • Helm Kubernetes functions such as lookup and some Capabilities values are not supported with the Native Helm and Replicated Helm deployment methods.

    This is because the app manager uses the helm template command to render chart templates locally. During rendering, Helm does not have access to the cluster where the chart will be installed. For more information, see Kubernetes and Chart Functions in the Helm documentation.

  • The following limitations apply to the native Helm deployment method:

    • 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 deployment method is not supported. To deliver applications using the Native Helm deployment method, promote releases to a new channel for new customer installations.
    • The test hook is not supported.
    • Hook weights below -9999 are not supported. 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 GitOps workflows. For more information, see Pushing Updates to a GitOps Workflow in the Enterprise documentation.
    • The name specified in the HelmChart custom resource must be an exact match to the actual Helm chart name that is provided to Replicated. If the Helm chart names do not match, then the installation can error or fail. See HelmChart in Custom Resources.

helm CLI Install Limitations​

The helm CLI installation method is Beta and has the following limitations:

  • "Last mile" changes with Kustomize are not supported. All configuration and customization must be done using Helm.
  • Strict preflights that block application installation are not supported. This is because Helm does not automatically run preflight checks. Preflight checks are supported with helm install, but your users must run the preflight checks manually before installing your application.
  • Air gap installations are not supported.
  • Customer adoption is not reported to the vendor portal.
  • This feature supports multiple charts and Replicated does not wrap or provide any special tooling to manage multiple charts. Replicated recommends that you provide installation instructions with sequenced steps for users to follow to install each chart in the required order.
  • The Replicated admin console is not included by default when your users install using the helm CLI. For more information about how to include the admin console with your application for helm CLI installations, see Delivering the Admin Console with your Application.