7.1. Creating a Chart
The first step, of course, would be to create a new chart with a given name:
Please note that the name of the chart provided here will be the directory's name where the chart is created and stored.
Let's quickly see the directory structure created for us:
Let's understand the relevance of these files and folders created for us:
- Chart.yaml: This is the main file that contains the description of our chart
- values.yaml: this is the file that contains the default values for our chart
- templates: This is the directory where Kubernetes resources are defined as templates
- charts: This is an optional directory that may contain sub-charts
- .helmignore: This is where we can define patterns to ignore when packaging (similar in concept to .gitignore)
7.2. Creating Template
If we see inside the template directory, we'll notice that few templates for common Kubernetes resources have already been created for us:
We may need some of these and possibly other resources in our application, which we'll have to create ourselves as templates.
For this tutorial, we'll create a deployment and service to expose that deployment. Please note that the emphasis here is not to understand Kubernetes in detail. Hence we'll keep these resources as simple as possible.
Let's edit the file deployment.yaml inside the templates directory to look like:
Similarly, let's edit the file service.yaml to look like:
Now, with our knowledge of Kubernetes, these template files look quite familiar except for some oddities. Note the liberal usage of text within double parentheses {{}}. This is what is called a template directive.
Helm makes use of the Go template language and extends that to something called Helm template language. During the evaluation, every file inside the template directory is submitted to the template rendering engine. This is where the template directive injects actual values into the templates.
7.3. Providing Values
In the previous sub-section, we saw how to use the template directive in our templates. Now, let's understand how we can pass values to the template rendering engine. We typically pass values through Built-in Objects in Helm.
There are many such objects available in Helm, like Release, Values, Chart, and Files.
We can use the file values.yaml in our chart to pass values to the template rendering engine through the Built-in Object Values. Let's modify the values.yaml to look like:
However, note how these values have been accessed within templates using dots separating namespaces. We have used the image repository and tag as “hello-world” and “1.0”, this must match the docker image tag we created for our Spring Boot application.
8. Managing Charts
With everything done so far, we're now ready to play with our chart. Let's see what the different commands available in Helm CLI to make this fun are! Please note that we'll only cover some of the commands available in Helm.
8.1. Helm Lint
Firstly, this is a simple command that takes the path to a chart and runs a battery of tests to ensure that the chart is well-formed:
The output displays the result of the linting with issues that it identifies.
8.2. Helm Template
Also, we've this command to render the template locally for quick feedback:
Please note that this command fakes the values that are otherwise expected to be retrieved in the cluster.
8.3. Helm Install
Once we've verified the chart to be fine, finally, we can run this command to install the chart into the Kubernetes cluster:
This command also provides several options to override the values in a chart. Note that we've named the release of this chart with the flag –name. The command responds with the summary of Kubernetes resources created in the process.
8.4. Helm Get
Now, we would like to see which charts are installed as what release. This command lets us query the named releases:
There are several sub-commands available for this command to get the extended information. These include All, Hooks, Manifest, Notes, and Values.
8.5. Helm Upgrade
What if we've modified our chart and need to install the updated version? This command helps us to upgrade a release to a specified or current version of the chart or configuration:
Please note that with Helm 3, the release upgrade uses a three-way strategic merge patch. Here, it considers the old manifest, cluster live state, and new when generating a patch. Helm 2 used a two-way strategic merge patch that discarded changes applied to the cluster outside of Helm.
8.6. Helm Rollback
It can always happen that a release went wrong and needs to be taken back. This is the command to roll back a release to the previous versions:
We can specify a specific version to roll back to or leave this argument black, in which case it rolls back to the previous version.
8.7. Helm Uninstall
Although less likely, we may want to uninstall a release completely. We can use this command to uninstall a release from Kubernetes:
It removes all of the resources associated with the last release of the chart and the release history.
9. Distributing Charts
While templating is a powerful tool that Helm brings to the world of managing Kubernetes resources, it's not the only benefit of using Helm. As we saw in the previous section, Helm acts as a package manager for the Kubernetes application and makes installing, querying, upgrading, and deleting releases pretty seamless.
In addition to this, we can also use Helm to package, publish, and fetch Kubernetes applications as chart archives. We can also use the Helm CLI for this as it offers several commands to perform these activities. As before, we'll not cover all the available commands.
9.1. Helm Package
Firstly, we need to package the charts we've created to be able to distribute them. This is the command to create a versioned archive file of the chart:
Note that it produces an archive on our machine that we can distribute manually or through public or private chart repositories. We also have an option to sign the chart archive.
9.2. Helm Repo
Finally, we need a mechanism to work with shared repositories to collaborate. There are several sub-commands available within this command that we can use to add, remove, update, list, or index chart repositories. Let's see how we can use them.
We can create a git repository and use that to function as our chart repository. The only requirement is that it should have an index.yaml file.
We can create index.yaml for our chart repo:
This generates the index.yaml file, which we should push to the repository along with the chart archives.
After successfully creating the chart repository, subsequently, we can remotely add this repo:
Now, we should be able to install the charts from our repo directly:
There are quite a several commands available to work with the chart repositories.
9.3. Helm Search
Finally, we should search for a keyword within a chart that can be present on any public or private chart repositories.
There are sub-commands available for this command that allows us to search different locations for charts. For instance, we can search for charts in the Artifact Hub or our own repositories. Further, we can search for a keyword in the charts available in all the repositories we've configured.
10. Migration from Helm 2 to Helm 3
Since Helm has been in use for a while, it's obvious to suspect the future of Helm 2 with the significant changes as part of Helm 3. While it's advisable to start with Helm 3 if we are starting fresh, support for Helm 2 will continue in Helm 3 for the near future. Although, there are caveats, and hence will have to make necessary accommodations.
Some of the important changes to note include that Helm 3 no longer automatically generates the release name. However, we've got the necessary flag that we can use to generate the release name. Moreover, the namespaces are no longer created when a release is created. We should create the namespaces in advance.
But there are a couple of options for a project that uses Helm 2 and wishes to migrate to Helm 3. First, we can use Helm 2 and Helm 3 to manage the same cluster and slowly drain away Helm 2 releases while using Helm 3 for new releases. Alternatively, we can decide to manage Helm 2 releases using Helm 3. While this can be tricky, Helm provides a plugin to handle this type of migration.
11. Conclusion
To sum up, in this tutorial, we discussed the core components of Helm, a package manager for Kubernetes applications. We understood the options to install Helm. Furthermore, we went through creating a sample chart and templates with values.
Then, we went through multiple commands available as part of Helm CLI to manage the Kubernetes application as a Helm package. Finally, we discussed the options for distributing Helm packages through repositories. In the process, we saw the changes that have been done as part of Helm 3 compared to Helm
