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:
- You can find a lot of Helm charts on the Artifact Hub
- You can deploy a Helm chart from a third-party provider (Datadog, Kubecost...)
- 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:
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* |
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
:
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-analyzerversion: 1.99.0repo_name: kubecostrepos:- name: stableurl: https://charts.helm.sh/stable- name: kubecosturl: https://kubecost.github.io/cost-analyzer/destinations:- name: defaultpath: ./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.0ADD . /helmENTRYPOINT ["/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 chartshelm-freeze.yaml
: configuration file for helm-freezerun.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
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.