How to deploy Helm charts

Use jobs to simply deploy Helm charts with Qovery (Kubecost example)

Helm is one of the most known tools to deploy on Kubernetes. It has several very useful features, Qovery uses it behind the scene to deploy some of its components. But you can also deploy Helm charts by your self if you wish.

Installing a chart can be useful for specific use cases:

  • When you want to deploy some specific objects on Kubernetes.
  • When a third-party vendor requires an installation with Helm.
  • When some specific configuration has to be set and does not fit into an application or container proposed by Qovery.

Choose a deployment method

There are several ways to deploy a chart:

  1. You can find a lot of Helm charts on the Artifact Hub
  2. You can deploy a Helm chart from a third-party provider (Datadog, Kubecost...)
  3. You can deploy a Helm chart from a private or public Git repository (Helm freeze is useful in this case)

We will make an example with all of these methods, so you can choose the one that suits you best. In all the examples, we will make use of the Lifecycle jobs to manage the deployment of your helm chart (install and uninstall). The Lifecycle job configuration will be different depending on the method you have chosen.

Lifecycle job parameters for Helm charts

From the Qovery Helm container, several options exist and are accessible through environment variables to help you to configure the chart deployment:

NameDescriptionDefault ValueRequired
HELM_REPO_ADD_NAMEThe Helm repository nameno
HELM_REPO_ADD_URLThe Helm chart URL (if none is specified, Artifact Hub will be used)defaultno
HELM_REPO_PATHThe local repository PATH or name from Artifact Hubyes
HELM_RELEASE_NAMEThe release name of the chart deployment (should be unique in a given namespace)yes
HELM_VALUESThe Helm chart values file path, containing your custom settings to override from the default valuesno
HELM_TIMEOUT_SECThe Helm timeout in seconds, to install and uninstall chart180no
HELM_MAX_HISTORYThe number of releases history. Useful to be able to rollback50no
HELM_DRY_RUNEnable or disable dry run for testing purposefalseno
HELM_SHOW_DIFFEnable or disable helm diff between the currently deployed version and the requested onefalseno
HELM_ADDITIONAL_PARAMSAdditional Helm CLI parameters to add to the command lineno
HELM_KUBERNETES_NAMESPACEKubernetes namespace name in which this chart will be deployed$QOVERY_KUBERNETES_NAMESPACE_NAMEno
KUBECONFIGThe Kubeconfig file path locationno*
KUBECONFIG_B64The encoded base64 Kubeconfig content. It will be decoded and used in KUBECONFIG environment variableno*
KUBECONFIG_GET_EKSSet to true to get the Kubeconfig from AWS API. It will be used as KUBECONFIG environment variablefalseno*

Chart deployment

In this tutorial, Kubecost will be the chart to deploy. You can deploy it in an environment where other applications are already deployed or create a dedicated one for this purpose (tooling, monitoring...).

From a 3rd party or Artifact Hub

First of all, create a Lifecycle Job:

create lifecycle job

Then select the Start event, and add ["install"] in the command arguments. In the Delete event, add ["uninstall"]. And configure them to run the install during the Start

lifecycle event

Click on continue and go up to the environment variables.

Qovery Helm image to deploy Helm charts, proposes several options to be set with the help of environment variables:

VariableValueSecret
HELM_REPO_ADD_NAMEkubecostno
HELM_REPO_ADD_URLhttps://kubecost.github.io/cost-analyzer/no
HELM_REPO_PATHkubecost/cost-analyzerno
HELM_RELEASE_NAMEkubecostno
HELM_KUBERNETES_NAMESPACEkubecostno

Additionally, you can set the Kubecost token if you have a license with additional Helm args like:

VariableValueSecret
HELM_ADDITIONAL_PARAMS--set kubecostToken="xxx"yes

From a Helm chart from a Git repository

If you prefer using a GitOps approach, having all your charts, etc... in a single Git repository, it is possible to deploy your charts this way.

From a very simple repository where we could have a helm-freeze configuration looking like this:

charts:
- name: cost-analyzer
version: 1.99.0
repo_name: kubecost
repos:
- name: stable
url: https://charts.helm.sh/stable
- name: kubecost
url: https://kubecost.github.io/cost-analyzer/
destinations:
- name: default
path: ./charts

Running helm-freeze sync will download the chart cost-analyzer into the charts folder. You can then use this simple Dockerfile which will add all the content of this git repository inside a container:

FROM qoveryrd/helm:1.0
ADD . /helm
ENTRYPOINT ["/helm/run.sh"]

Finally, add the run.sh file from the Qovery Helm image inside your repository. Commit now everything. To summarize, in your Git repository you should have:

  • charts: a folder containing all the charts (here cost-analyzer chart)
  • Dockerfile: helping you to deploy helm chart and containing all your charts
  • helm-freeze.yaml: configuration file for helm-freeze
  • run.sh: the container start script

We are now ready to create a Lifecycle job and select your repository:

create lifecycle job

Then select the Start event, and add ["install"] in the command arguments. In the Delete event, add ["uninstall"]. And configure them to run the install during the Start

lifecycle event

Set the environment variables to point to the chart to deploy with the release name and other required information:

VariableValueSecret
HELM_REPO_PATH/helm/charts/cost-analyzerno
HELM_RELEASE_NAMEkubecostno
HELM_KUBERNETES_NAMESPACEkubecostno

Additionally, you can set the Kubecost token if you have a license with additional Helm args like:

VariableValueSecret
HELM_ADDITIONAL_PARAMS--set kubecostToken="xxx"yes

Lifecycle Job and Timeout management

The default Helm timeout set by Qovery is 3 minutes. Qovery enables Helm options:

  • --wait: to wait for all resources to be in a ready state before marking the release as successful
  • --atomic: to roll back the release if the deployment fails

Because of the atomic check, the rollback can take more than 5 minutes. By default, Qovery set the default Lifecycle timeout to 3 minutes, to avoid falling into this issue, but there is no guarantee, it depends on what resources are deployed:

Qovery strongly recommends leveraging the default Qovery Lifecycle Job timeout or reducing the default Helm timeout to ensure the rollback will occur properly in case of failure.

Conclusion

As you can see, deploying Helm charts with Qovery is straightforward. Qovery Lifecycle jobs and its Qovery Helm image should help you a lot if you familiarize yourself with it and its options.