Throughout the years in IT, every engineer has worked with a package manager in some way, shape, or form. Whether it was on an Ubuntu box with Aptitude, a Windows laptop with Chocolatey, or a package manager for a programming language like NPM or Pip3.
Package managers are key to consolidating all necessary resources for a particular application or tool to work properly.
In this blog post, you’ll learn how Helm Charts implement the same thought process.
What Are Helm Charts
In the opening of this blog post, package managers were mentioned. If you’re wondering why, it’s because Helm is a package manager.
Helm Charts consolidate multiple Kubernetes Manifests into one location and allow you to package them together in said location so they can be deployed together at the same time.
For example, take a look at the below screenshot. It consists of two main parts:
- The nginx directory.
- The templates directory.
The nginx directory is what holds all of the files (YAML) necessary to package up the Chart. The files are everything from Kubernetes Manifests to value files that are being passed in at runtime. This allows for you to take every Manifest file from the deployment.yaml to the service.yaml to the ingress.yaml, put them in one location, and deploy them together (hence package manager).
The templates directory hold the Kubernetes Manifests, but they aren’t normal Kubernetes Manifests. They are templates of what your Kubernetes Manifest would typically look like. The templates allow you to pass in values at runtime.
In the screenshot below, you can see the {{ .Values.app }} entry. This entry tells the template that the value for the app name is within the values.yaml file, which is a file that you store all of the parameters in for runtime.
Putting it all together, Helm Charts gives you the ability to package up Helm Charts for Kubernetes Deployments.
What Value Do Helm Charts Provide
Helm Charts provide two primary pieces of value:
- Consolidating Kubernetes Manifests.
- Passing in values at runtime.
If you’re deploying any containerized application to Kubernetes, you’re going to have more than one Manifest. Whether it’s one or more deployment.yaml’s, service.yaml’s, ingress.yaml’s, configmap.yaml’s, etc., there will be more than one. Often times, there are 5+. Deploying these all separately and managing them separately can be a cumbersome task. It’s a lot of manual effort. With Helm Charts, you can consolidate all of the Manifests into one location and deploy them as one. This process helps a ton with race conditions as well.
As you look at all of the Manifests you have to deploy, you may say to yourself “huh, not only do I have a lot of Manifests to deploy, but I need to deploy them for Dev, Staging, and Production”, and most of the time it’s a small change. For example, imagine having to have three different Manifests because the replica count for a Deployment changes between Dev, Staging, and Prod? It’s literally one minor integer change that causes you to have multiple files to manage. Instead, you can use the values.yaml file and pass in values at runtime per environment.
Helm Charts vs Kustomize
From a values.yaml perspective, or rather, passing in values at runtime, Helm compares pretty closely with Kustomize.
Kustomize is a configuration management tool for Kubernetes. In short, it allows you to pass in values at runtime for various environments and it does so pretty similarly to Helm Charts.
The key difference with Kustomize is you don’t have to change any code in your Kubernetes Manifest and templatize it like you do with Helm.
For example, let’s say you had a deployment.yaml Manifest. You’d put that Manifest in a directory called “base” without changing anything. Within the “base” directory”, you’d also have a kustomization.yaml file which points Kustomize to the Manifests that you want to alter with Kustomize.
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
You’d then create an “overlays” directory that contains all of your environments (Dev, Staging, Prod, etc.). Each environment will have a kustomization.yaml file that shows what you want to edit within the Manifest. Below is an example altering the Replica count.
When You Shouldn’t Use Helm Charts
Helm Charts aren’t a huge lift to implement, but they may be overkill. For a lot of environments, engineers will use Helm Charts as a way to pass in values at runtime with the values.yaml file. If this is the only use case you need Helm Charts for, chances are you’re better off just using Kustomize instead. It’s a lower lift, easier to configure, and you don’t have to worry about any templating.
If you have a need to deploy your Kubernetes Manifests together and package them up, Helm Charts are the way to go.
If you have any queries, don't hesitate to connect with us. Join the lively discussions and shared knowledge in our vibrant Discord Community.
