Helm: Why DevOps Engineers Love it?

Published 28.05.2021

Author Hrittik Roy

Categories Engineering

Kubernetes doesn’t have reproducibility built-in.

At least, that’s what we hear most people complain as a cloud native consultation firm serving both startups and enterprises.

I have been using Kubernetes for a while now, and it stands up to the mark of being a gold standard container orchestration tool. Sharing is caring, so I wrote a blog about it too.

A thing people often forget is that Kubernetes never was intended to have reproducibility in its scope. Still, its presence under CNCF ☂ makes it natively compatible with other projects specializing in managing reproducibility.

So, in this post, let’s dive in through a CNCF graduated project that supports k8s natively and can be a solution to all your reproducibility problems.

How does one get reproducibility from k8s?

The answer is simple, use a package manager that would install packages in your cluster.

The package would contain a reproducible template that can be used to create your entire scalable infrastructure with one command and remove the manual effort of listing each file using kubectl.

The CNCF ☂ provides you with a project named Helm. Learn more about CNCF here.

What is Helm?

Helm is a package manager that has native support for Kubernetes (from the 1.4 release). Now a graduated CNCF project, Helm resulted from a collaboration between Deis (a container tooling business that Microsoft now owns) and Google.

Helm allows you to install packages in your cluster, much like you would use apt, yum on your laptop. Just define the components that you want to install in your application, and it will take care of the installation and configuration of these components, saving you from headaches.

Helm Deployment Life Cycle
Helm Deployment Life Cycle Source: Microsoft

Despite its appearance, its reach extends well beyond that of a mere package manager. It’s a breathing project and changes heavily from version to version, with more functionalities added to it with the subsequent release. However, let’s start at the beginning and understand what’s capable of with a high-level overview.

Helm: The package manager for Kubernetes

DevOps teams use Kubernetes YAML files to configure Kubernetes workload. These YAML files define everything required for container deployment. Everything from how each Pod must be configured to how the Kubernetes cluster handles load balancing must be specified in those YAML files.

As a result, in order to set up a new Kubernetes workload, you must first build a YAML file for that workload. To do it manually, you’ll need to create multiple YAML files, one for each task.

Helm Charts

Rather than writing individual YAML files for each application, you can create a Helm chart and let Helm deploy the application to the cluster for you. Helm charts are collections of templates for multiple Kubernetes resources that work together to construct an application. When deploying a Helm chart on several Kubernetes clusters, it can be customized. Helm charts can be built in such a way that environment or deployment-specific configurations can be extracted to a separate file, and afterward, these values can be specified when the Helm chart is deployed.

Helm Chart Process
Helm Chart Process Source: Microsoft

You can use one chart with different variables in your development, staging, and production environments—no need for multiple charts.

Helm repository

Now that you’ve generated your chart, what should you do? You upload it to a repository.

Is it necessary to download the entire repository to install those charts? No way! Helm includes a public library for the most often used charts, similar to Docker Hub.

You can also construct and host your own chart repository online and download charts from these repositories. You would find most of the charts required by you already hosted on the Helm repository. Explore the repository here.

Helm Repository
Helm Repository Source: Microsoft

Because a chart repository is essentially an index.yaml file served from a static web server, you can make one anywhere you want. This allows you to have a private chart on your intranet or local server.

You can also try other open-source alternatives like ChartMuseum, an open-source Helm Chart Repository server written in Go (Golang), with support for cloud storage backends, including Google Cloud Storage, Amazon S3, Microsoft Azure Blob Storage, and other cloud providers.

Easy Updates

Helm has the ability to adjust application configurations during deployment. The DevOps team may set the Kubernetes resources used in the application and all of the environment-specific needs for those resources. This allows teams to reuse a single Helm chart across many environments and easily update dependencies of previously deployed infrastructure.

Rollbacks

Helm keeps track of all the versions of your releases in a database. So, if something goes wrong during deployment, reverting to the prior version is as simple as one command.

Drawbacks

Troubleshooting and Debugging

If I am honest, Helm is quite complex. As the entire system is dependent on templating Helm charts, it is complicated to design and debug big applications that may include several Kubernetes resources. The more Helm charts there are, the more complicated the system becomes. Consider how long it would take a team to identify and fix a bug in a Helm chart template that has been used several times across several Kubernetes resources in a complicated application.

Learning curve

Helm makes it easier to manage Kubernetes clusters. However, producing the first Helm chart is not as straightforward as running a few commands. The procedure is highly complex, with a high learning curve that may take some time for DevOps teams to adjust. Helm aims to make things as simple as possible by providing extensive documentation on how to perform things.

Final Thoughts

With its versioned charts, Helm has proven to be a valuable tool in maintaining today’s complex infrastructures. Furthermore, the project has reduced the time it takes to develop environments in production services and locally.

Another option for reproducibility is to use Kustomize, a template-free way to customize application configurations and manage Kubernetes workloads. Both Helm and Kustomize are used depending upon use cases, and let’s keep the details for some other day.

Feel free to try Helm out and we are a text away if you want help accelerating your cloud native or reproducibility adoption.

You can check a few of our recent deep dives here:

Happy Learning!

Join 100+ cloud native enthusiasts

and stay in the loop on modern software development.

Sign up to receive exclusive content around cloud native software development right into your inbox.

We don’t spam! Read our privacy policy for more info.

More stories from our blog

What is cloud native?

What is cloud native?

Cloud native is a term that has been around for a while, but it’s still not well understood. The term was first used in 2010 by Adrian Cockcroft, then VP of cloud architecture at Netflix. He defined it as: “The application is designed from the ground up to take...

Three Monsters: The path to Self Growth

Three Monsters: The path to Self Growth

If you ever take a journey down your daily journal, you would find certain traits that set you back and harm your trajectory to success. Now, if you are busy and don’t have time to write a journal (aka no time for self-discovery) but want to discover these traits (I...

Proxy Servers: The Captivate Shield

Proxy Servers: The Captivate Shield

If you have been scrolling the web, you would have heard about the terms proxy and reverse proxy at least once. You might know a bit of them or might be completely unaware of what they are. This is completely okay with me, and if you have the desire to understand...

Service Mesh: The Gateway to Happiness

Service Mesh: The Gateway to Happiness

Microservices have lead the human race away from monolithic applications to a cloud native landscape. The dominance of microservices (containers) has impacted the modern development environment to be scalable, flexible and continuous. But as the number of...

CNCF: Forefront of the Cloud Native Landscape

CNCF: Forefront of the Cloud Native Landscape

Cloud Native Computing Foundation or CNCF is a term you would see flying all around the cloud native landscape. You might know about it a bit as a prominent organization that maintains your frequently used open source tools like Kubernetes, Prometheus (and more!)...

Kubernetes: The Ultimate Guide

Kubernetes: The Ultimate Guide

The demand around scalable and reliable services is increasing every day exponentially. The market is driven by customers demanding their favorite services to have zero downtime and companies that lose millions of dollars for every minute they’re down. If you have...

Turbo-charge with Container Orchestration

Turbo-charge with Container Orchestration

Managing containers while traffic increases or decreases in cost-effective ways round the clock sounds challenging and complex without tools. We, as cloud-native citizens, crave scalability and agility. But our containers going into production without the cloud-native...

Unikernel Vs Container Vs VMs: Here is what you should use

Unikernel Vs Container Vs VMs: Here is what you should use

If you’d gone through Containers, Unikernels and VMs, I would bet you’re confused about which one to try for your new venture. It’s normal and happens to everyone while experimenting with adopting new technology. Remember the age-old dilemma of you thinking which...

Interested in what we do? Looking for help? Wanna talk about software strategy?