What is Helm?

In this blog, we will get an introduction to Helm. Kubernetes is awesome at managing complex infrastructures. We, humans, tend to struggle with complexity, though. And applications we deploy into our Kubernetes cluster can become very complicated.

A typical app is usually made up of a collection of objects that need to interconnect to make everything work. For example, even a relatively simple WordPress site might need the following:

• A persistent volume to store the database
• A persistent volume claim
• A service to expose the web server running in a pod, to the Internet
• A secret to store the admin password
• A deployment to declare the pods you want to run: MySQL database servers, web servers, etc.
• And maybe even more if you want extra stuff like periodic backups and so on.

For every object, we might need a separate .yaml file. Then we need to “kubectl apply -f” every .yaml file. This can be tedious, but it’s not the end of the world. But imagine we download these yaml files from the Internet. We’re not happy with the defaults so we start changing stuff.  The persistent volumes are 20GB, but we know our website will need much more storage. We go to the .yaml files where persistent volumes/claims are declared, we change 20 to 100. More stuff we want to change? We’ll have to open up every yaml file and edit each one according to our needs. Not bad enough yet? Now imagine 2 months go by. We now have to upgrade some components in our app. Back to editing multiple yaml declarations, with great care, so we don’t change the wrong thing in the wrong place. Need to delete the app? We’ll need to remember each object that belongs to our app and delete them all, one by one. This would translate into many commands like

kubectl delete -f wordpress-service.yaml
kubectl delete -f wordpress-deployment.yaml
kubectl delete -f wordpress-pvc.yaml

# and so on

But some people might be thinking, “Hey, it’s no big deal, we can just write all object declarations in a single yaml file.” That’s true, but it might make it even harder to find the stuff we’re looking for. We’d have to continuously search for stuff we need to edit in something that could be 25 pages of text. At least in multiple files, they’d be somewhat organized and we’d know we’ll find deployment-related stuff in “mysql-deployment.yaml”.

Enter Helm!

Helm changes the paradigm. Kubernetes doesn’t really care about our app, as a whole. All that it knows is that we declared various objects and it proceeds to make each of them exist in our cluster. It doesn’t really know that this persistent volume and that deployment and that secret and that service are all part of a big application called WordPress. It looks at all the little pieces that the administrator wanted to have in the cluster and takes care of each one, individually.

Helm, however, is built from the ground up to know about such stuff. That’s why it’s sometimes called a package manager for Kubernetes. It looks at those objects as part of a big package, as a group. Whenever we need to perform an action, we don’t tell Helm the objects it should touch. We just tell it what package we want it to act on, like our WordPress app/package. Based on the package name, it then knows what objects it should change and how, even if there are 100 objects belonging to that package.

To make this easier to understand, think about this. A computer game is contained in hundreds or thousands of files. There are a few files with the program’s executable code, other files with audio, game sounds and music, other files with graphics, textures, images, files with configuration data and so on. Now imagine we’d have to download each of them separately. Wow, would that be tedious. Fortunately, we don’t have to go through such horrors, as we get a game installer. We run it, we press “next, next, next”, choose the directory where we want to install, game settings, and the installer does the rest, putting thousands of files in their proper location. Helm does a similar thing (and more) for the yaml files and Kubernetes objects that make up our application.

Hence, we get advantages like these:

• We use a single command to install our whole app, even if it needs 100 objects. Then Helm proceeds to automatically add every necessary object to Kubernetes without bothering us with the details.
• We use a single command to uninstall our app. It keeps track of all the objects used by each app so it knows what to remove. We don’t need to remember each object that belongs to one of our apps anymore, or use 10 separate commands to remove everything. Helm does all the work.
• We can customize the settings we want for our app/package, by specifying desired values at install time. But instead of having to edit multiple values in multiple .yaml files, we have a single location where we can declare every custom setting. In a file like “values.yaml” we can change the size of our persistent volumes, choose the name for our WordPress website, the admin password, settings for the database engine, and so on.
• We can upgrade our application with a single command. Helm will know what individual objects need to change to make this happen.
• We can rollback to the previous so-called “revision”. For example, if we upgrade a Helm package/app, this might take us from revision number 4 to revision number 5. If the upgrade doesn’t work how we pect, maybe we get new bugs we don’t like, we can rollback (revert) to the previous revision and go back from 5 to 4. Although similar, this shouldn’t be confused with restoring from a backup. It does not get old data back. For example, if we accidentally deleted a database, this will not recover it. Helm rollbacks are just a way to get the Kubernetes objects of our app back to the exact state they were before, in a previous revision.
• We can also potentially use Helm to automate installs. For example, imagine the following scenario. A user makes a request on our website, he chooses some settings. These settings get passed on to a Helm command which then launches an app according to the user’s preferences.

So Helm works as a sort of install wizard (or package manager), uninstall wizard but also as an upgrade/rollback manager (release manager). The core thing is that it lets us treat our Kubernetes apps as apps, instead of as a collection of objects. This takes a huge burden off our shoulders, as we don’t have to micromanage each Kubernetes object anymore, Helm can do that for us.

Want to learn more about Helm’s basic concepts and features? Check out this video.

Checkout the Helm for the Absolute Beginners course here

Checkout the Complete Kubernetes learning path here