Upgrade Native Helm 2 Deployments to Helm 3

Updated 2 weeks ago by Michael Cretzman

For Kubernetes deployments that use Helm charts, see Upgrade to Helm 3 Charts in Kubernetes Services.

When you create your native Helm deployments in Harness, you can choose to use Helm 2 or Helm 3.

If you have already created native Helm 2 deployments, you can upgrade your deployments to Helm 3 by following the steps in this topic.

What's a native Helm deployment in Harness? Harness provides Kubernetes deployments that use Helm charts without requiring Helm or Tiller be installed in your target environment. These are called Harness Kubernetes deployments. This is the recommended method. If you want to deploy to a Kubernetes cluster using Helm explicitly, you can use native Helm deployments. You simply choose Helm as the Deployment Type when you create a Harness Service.

In this topic:

Before You Begin

Blog Post

The following blog post walks you through creating a Helm 3 deployment from scratch using Harness, including a video walkthrough:

Welcome to the Harness Family, Helm V3!

Optional: Migrate Your Release History From Tiller

This section is not necessary for Harness Kubernetes deployments that use Helm charts. For Kubernetes Services, see Upgrade to Helm 3 Charts in Kubernetes Services.

Helm 3 uses a new data data model that impacts your native Helm deployment release history. If you upgrade Harness native Helm 2 deployments to Helm 3 without migrating your target cluster to Helm 3, your Helm 3 deployments will not include your Helm 2 release history.

If maintaining continuity between your Helm 2 and Helm 3 releases is not required, you do not need to migrate your release history to Helm 3. Simply move onto the next steps.

If you do not migrate your release history to Helm 3, the first time you deploy to it using a Harness native Helm 3 deployment, Harness cannot perform rollback because there will no release history available.
  1. If you want to maintain release continuity between Helm 2 and Helm 3, migrate your release history to Helm 3 using the steps in How to migrate from Helm v2 to Helm v3 from Helm.

    In particular, pay attention to the steps in the Migrate Helm v2 Releases.

Once you are done migrating, follow the steps below.

Step 1: Add a new Delegate with Helm 3 Installed

If you are upgrading your native Helm deployments to Helm 3, you will need to add a new Harness Delegate and install Helm 3 on it.

  1. Install and run a new Kubernetes Cluster Delegate or Helm Delegate in your target cluster, or install a new Helm Delegate using the Kubernetes management platform, Rancher. For steps on setting up a new Delegate, use one of the following:
  1. Install and run Helm 3 on the new Delegate.
    You can install and run Helm 3 manually, or create a Delegate Profile for Helm 3 and apply it to your new Delegate.
    The Helm 3 Delegate Profile should simply contain the following:
curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash

This script will add Helm to the Linux PATH.

For all options, see Installing Helm from Helm.

Step 2: Enable Helm 3 on Harness Services

  1. Log into Harness.
  2. Click Setup, and open your Harness Application.
  3. Open the Harness Service you use for native Helm 2 deployments.
  4. In the Harness Service, click vertical ellipsis (︙) and then click Edit:
  5. Select the Enable Helm V3 setting and click Submit.

That's it. Now your Harness Service is upgraded for Helm 3 and you can start using Helm 3 charts.

Troubleshooting

If your deployment uses Helm 3, Harness will select a Delegate that has Helm 3 installed. You do not need to make any changes.

However, if the Infrastructure Definition used by the Workflow is configured with a Cloud Provider that uses the Delegate Tag of a Delegate that is running Helm 2, your Helm 3 deployment might fail.

After you have installed and run your new Delegate, and installed and run Helm 3 on it, Tag your new Delegate and change your Cloud Provider to use its Delegate Tag.

How did we do?