In our recent article about the Top CNCF Projects to look out for in 2023, we highlighted Helm as “the package manager for Kubernetes.” If you have ever wondered why would Kubernetes need a package manager, what’s actually the use of Helm, or if it’s something that you, as a developer, should even care about, keep reading because you may be in for a treat.
Kubernetes package manager
Helm is a Kubernetes package manager, just like apt, yum, or homebrew are package managers for different operating systems. It is used to manage Kubernetes applications – install, update, or uninstall them. If you develop applications for and/or with Kubernetes, you may find it very useful. Later on, we will discuss a few use cases for developers, but for now, let’s dive into what exactly is Helm.
What the Helm… ? – Helm, explained
We just said that Helm is a package manager for K8s. So there must be packages to manage, right? Well, they are called charts, and they contain all the necessary resource definitions to run an application, tool, or service in a Kubernetes cluster. There are chart developers – sometimes the application creators, sometimes from the community – that define a default configuration to help you get started with the chart.
In fact, what they create is a structured directory with a series of specific files. The usual YAML manifests are written as templates, and the actual values are listed in a different file. This way, you as a user only need to modify the values that are passed to the chart. You can also overwrite values by passing them along with the command calls.
Charts are collected and shared in repositories. The official Helm repository is the Artifact Hub. It lists Helm charts from dozens of different repositories. However, you can also have your local repository and grab charts from there. You just need to register it with your Helm client.
When you choose and install a chart to your Kubernetes cluster, you create a release. This is an instance of a chart running in a cluster. You can install the same chart many times, and each time you create a new release with its own release name.
Chart, repository, and release are the key concepts of the Helm architecture. You can read more about them in the project documentation. Rajesh P also has a really understandable description of Helm in this blog post.
Manage Kubernetes
Helm aims to simplify common tasks with Kubernetes applications with just a few simple commands.
Easy installation
You can simply grab and install a chart for even the most complex K8s application. Having all the configuration files ready will save you a lot of time and headaches.
Easy updates
If you are working on an application and production requirements change down the line, you may need to adjust the configuration. You may be familiar with the configuration files and know where to modify some values. But if the project is new to you, you may be lost. Having all the values in a single file makes it so much easier – and faster – to update an application.
Easy rollbacks
Helm stores a history of revisions for each release. Each time an update is made, Helm keeps a snapshot of how the application is configured for the current revision. If you need to make a rollback, it is as simple as pointing Helm to a previous one. It will revert the live state of the application to that of the selected revision.
Simple sharing
Charts are easy to version, share, and host on public or private servers. The official Helm repository is Artifact Hub, which is in fact a community repository of artifacts for any CNCF project. You can also create and run your own chart repository for local use. You can find more information on how to do it in this guide.
Napptive enables developer self-service. We encourage you to try our playground and experience accelerated cloud-native development. It’s completely free, all you need to do is simply sign up and get started!
I need Helm with Kubernetes – use cases for developers
Here are some scenarios where you will find Helm very helpful:
- For medium to complex deployments – If you are somewhat comfortable with Kubernetes you can choose to deploy simple projects on your own. However, when you need a few parts to your deployment, you may want to rely on the configuration that someone else has already made. For example, if you want to deploy a Grafana server on Kubernetes you’re probably going to need at least a Deployment and a Configmap, and a service that matches this deployment. And if you want to expose it to the internet, you need an ingress too. A relatively simple application would require four different YAMLs that you would have to configure manually and make sure everything is correct.
- For convenience – The Helm values mechanism gives a uniform way to specify service-specific controls, like the log level or external database hostnames, without needing to know the details of the Kubernetes YAML files.
- For standardizing deployments in your CI/CD pipeline – When you are routinely producing new builds and sending them to the Kubernetes cluster, you can use templating to specify the image name and tag in a deployment. Then, you just ask Helm to upgrade the application by requesting a specific tag.
There are many other use cases, and even combinations of the above, but the ones listed here are the most common.
Conclusion
Helm is a tool for developers that aims to ease the configuration work. If you are ready to start using Helm, just go to the Quickstart Guide of the project documentation. Or if you want to know more about charts and how to create one, visit their Getting Started guide.
In case you have not yet tried Napptive, we encourage you to sign up for free and discover how we are helping propel the development of cloud-native apps.
