Kubernetes, the de-facto standard for container orchestration, supports two deployment options: imperative and declarative.
Because they are more conducive to automation, declarative deployments are typically considered better than imperative. A declarative paradigm involves:
The issue with the declarative approach is that YAML manifest files are static. What if you want to deploy the same app in two different environments (for example, “staging” and “production”) with some slight changes (for instance, allocating resources to production)? Having two YAML files is inefficient. A single parameterized YAML file is ideal for this scenario.
Helm is a package manager for Kubernetes that solves this problem. It supports manifest templating and enables parameterization of otherwise static YAML configurations. A set of templated manifest files.
A Helm chart is a package consisting of templated manifest files and metadata that can be deployed into a Kubernetes cluster. A Helm chart takes input variables and uses them to process templated YAML files to produce a manifest that can be sent to the Kubernetes API.
Before deploying a Helm chart into your Kubernetes cluster, it’s wise to understand how it will behave. Helm dry run — specifically the helm install --dry-run command — addresses this use case and enables a preview of what a Helm chart will do without deploying resources on a cluster. Helm dry run also streamlines troubleshooting and testing Helm charts.
This article will take a closer look at Helm dry run concepts, including related Helm commands and how to use Helm dry run to troubleshoot templates.
The table below summarizes the Helm dry run concepts we will explore in this article.
The three Helm commands we will explore in this article are:
The helm template command renders the template but does not check the validity of the generated YAML files beyond a simple YAML syntax check. It will stop generating the output when it encounters invalid YAML. Use the --debug flag to force the helm template command to display full output, including invalid YAML.
The helm template command has the advantage of not needing a running cluster. Use cases for helm template include:
The helm lint command runs a basic static analysis that checks a Helm chart for potential bugs, suspicious constructs, and best practices deviations. This command is only useful when writing a Helm chart.
The helm install --dry-run command requires a running Kubernetes cluster and will test the manifest against that specific cluster. This is useful because a Helm chart may be compatible with one cluster but not another. Potential differences across clusters include:
Now let’s look at how to run the helm template command.
First, let’s create a simple Helm chart:
This will create a simple chart deploying NGINX. Now let’s see what the helm template command shows:
Next, let’s introduce an error in one of the YAML manifest files. Edit the “mychart/templates/serviceaccount.yaml” file and add some invalid YAML like this:
Let’s see what the helm template command does now:
As we can see, it failed because the YAML is invalid. We can view the invalid output with the --debug flag:
As you can see, the errors eventually cause Helm to crash. But at least you should have gotten enough output to troubleshoot your problem. Using helm template --debug is mostly useful when writing a Helm chart and you need to understand whether your Helm chart is doing what you want.
Lastly, let’s explore the helm template command’s main limitation: it generates output even if the result is not a valid Kubernetes manifest. To demonstrate, edit the previous file, undo the error we introduced, and modify it like this:
There is no kind “ServiceAccountInvalid” in Kubernetes, so let’s see what the helm template command will do:
As you can see, helm template happily generates the output, even though it is not a valid Kubernetes manifest file.
The helm lint command tests whether a generated manifest can be deployed on a specific Kubernetes cluster. This helps address issues such as helm template generating invalid manifest files and provides static analysis during chart creation.
The helm lint command is run like this:
Helm will flag potential issues and make some recommendations related to best practices.
In this tutorial, we’ll use the helm install --dry-run command to validate a Helm chart without actually deploying it on a cluster.
To keep things simple for this tutorial, we’ll run a local minikube cluster, but you can use any compatible cluster deployment to follow along.
If we run the helm install --dry-run command with the flawed Helm chart we used in the previous section, here is what happens:
As we can see, the helm install --dry-run command connects to the Kubernetes API and sends the resulting manifest file for verification, which fails as expected. Now let’s edit the “mychart/templates/serviceaccount.yaml” again and fix the error we introduced.
After the edits, the command will succeed:
Finally, to demonstrate that the command connects to the Kubernetes API, let’s delete the minikube cluster and rerun the command:
The helm template command generates a given Helm chart's output manifest and simulates output for input variables. It checks the YAML syntax of the generated output but does not check whether the output is a valid Kubernetes manifest. It is useful both when writing a Helm chart and before deploying a Helm chart into an existing cluster.
The helm lint command performs static analysis to check Helm charts for potential bugs, suspicious constructs, and deviations from best practices. This command is primarily useful when writing a Helm chart.
The helm install --dry-run command goes one step further and sends the manifest to the Kubernetes API for verification. This enables testing a Helm chart and its variables on an existing cluster. The helm install --dry-run command is useful before actually installing a Helm chart.
Together, these Helm commands can help you improve the quality of your Helm charts and troubleshoot complex Kubernetes issues.