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 of 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

Qovery provides a Helm container, simplifying the Helm chart deployments, but you can do it your way if you prefer. The container image is qoveryrd/helm.

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

Name	Description	Default Value	Required
HELM_REPO_ADD_NAME	The Helm repository name		no
HELM_REPO_ADD_URL	The Helm chart URL (if none is specified, Artifact Hub will be used)	default	no
HELM_REPO_PATH	The local repository PATH or name from Artifact Hub		yes
HELM_RELEASE_NAME	The release name of the chart deployment (should be unique in a given namespace)		yes
HELM_VALUES	The Helm chart values file path, containing your custom settings to override from the default values		no
HELM_TIMEOUT_SEC	The Helm timeout in seconds, to install and uninstall chart	180	no
HELM_MAX_HISTORY	The number of releases history. Useful to be able to rollback	50	no
HELM_DRY_RUN	Enable or disable dry run for testing purpose	false	no
HELM_SHOW_DIFF	Enable or disable helm diff between the currently deployed version and the requested one	false	no
HELM_ADDITIONAL_PARAMS	Additional Helm CLI parameters to add to the command line		no
HELM_KUBERNETES_NAMESPACE	Kubernetes namespace name in which this chart will be deployed	$QOVERY_KUBERNETES_NAMESPACE_NAME	no
KUBECONFIG	The Kubeconfig file path location		no*
KUBECONFIG_B64	The encoded base64 Kubeconfig content. It will be decoded and used in KUBECONFIG environment variable		no*
KUBECONFIG_GET_EKS	Set to true to get the Kubeconfig from AWS API. It will be used as KUBECONFIG environment variable	false	no*

KUBECONFIG, KUBECONFIG_B64 or KUBECONFIG_GET_EKS are required to be set to access Kubernetes cluster

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...).

You will have to configure the KUBECONFIG, KUBECONFIG_B64 or KUBECONFIG_GET_EKS environment variable to be able to deploy the chart. It is mandatory to ensure Helm will be able to connect to your Kubernetes cluster. You may also have to push AWS credentials (with eks:DescribeCluster permissions) or use AWS IAM roles.

From a 3rd party or Artifact Hub

First of all, create a 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

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:

Variable	Value	Secret
HELM_REPO_ADD_NAME	kubecost	no
HELM_REPO_ADD_URL	https://kubecost.github.io/cost-analyzer/	no
HELM_REPO_PATH	kubecost/cost-analyzer	no
HELM_RELEASE_NAME	kubecost	no
HELM_KUBERNETES_NAMESPACE	kubecost	no

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

Variable	Value	Secret
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:

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

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

Variable	Value	Secret
HELM_REPO_PATH	/helm/charts/cost-analyzer	no
HELM_RELEASE_NAME	kubecost	no
HELM_KUBERNETES_NAMESPACE	kubecost	no

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

Variable	Value	Secret
HELM_ADDITIONAL_PARAMS	--set kubecostToken="xxx"	yes

Lifecycle Job and Timeout management

Helm timeout and Qovery Lifecycle job should be correctly set to avoid board effects!

Qovery Liefcycle Job timeout > ( Helm deployment timeout + Helm rollback time )

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.