What the Helm?! The Tool We All Love (and Sometimes Hate)
This is part of a series of contributed articles leading up to KubeCon + CloudNativeCon on Oct. 24-28.
Helm is a project that has gained incredible adoption over the past few years and has become one of the de facto tools for installing, configuring, packaging and managing applications in Kubernetes, particularly at scale, where more control of clusters is a must.
Widespread adoption and usage, though, often comes with notoriety. Whether you love it or hate it, most people have some staunch opinions about Helm, and in this post we’re going to cover it from all its angles: the good, the OK and the ugly. We’ll allow you to decide. This post will help you decide whether this is a tool you’d like to use, and if you’re already using it, we’ll provide ways to help you optimize the experience.
But before we get into it, Helm’s history deserves a word or two. It all started from an internal hackathon at Deis and was created for their internal use to wrangle their own Kubernetes clusters. Once it gained maturity, they decided to open source the project and contribute it to the Cloud Native Computing Foundation (CNCF).
A couple of years later, after gaining much organic popularity in the form of users and contributorship expected of a mature project, Helm officially graduated from incubation to be a CNCF-hosted project and is even considered an integral part of the Kubernetes stack today.
Helm certainly has its upsides and its quirks, some that are forgivable and others that produce a lot of head-scratching moments. This is true both when getting started with Helm, and when managing it in the long term and navigating its operational complexity. Let’s unpack why and how this happened and what you should know before getting started — and after going over the deep end.
Why, What, How?
Helm gained rapid adoption because of the role it fulfills in the Kubernetes ecosystem. When look at Kubernetes as a project, there’s no doubt that its strength is in deploying objects and orchestrating containers. Today’s applications are no longer the monoliths of once upon a time. Instead, they’re composed of many modular services, almost like building blocks, and this is a playground in which Kubernetes made it super easy to create. In other words, the possibilities were endless.
This was fun with single applications, but once you needed to start doing this with many applications, management and maintenance became increasingly difficult. Before Helm was born, you needed to create huge single files and deploy them to K8s or do kubectl apply on top of a whole directory, which was extremely messy.
This was the landscape that Helm was conceived and created in, and the quote below captures exactly what the team was looking to achieve:
“‘Zero to dopamine in five minutes.’ That was our Helm mantra: We saw an opportunity to make Kubernetes more approachable to newcomers. If we did things right, users could install Helm and then within minutes be installing production-grade off-the-shelf components.”
(From Celebrating Helm’s CNCF Graduation)
Helm’s success is basically what deepened use of Kubernetes as a whole. It revolutionized the way apps can be deployed and run in Kubernetes. By creating an open contribution model and allowing vendors and developers to create their own certified and maintained charts that were then distributed to the community, it became possible to deploy even complex applications. Platforms like Grafana, Elastic and Redis, were all up in minutes with a Helm chart, without really having to know Grafana, nor Kubernetes, at all.
This changed the industry and Kubernetes adoption for the better, enabling developers to build a lot of tools without needing to have in-depth prerequisite knowledge.
However, this kind of simplicity is a double-edged sword as the deployment is always the easy part. It’s the maintenance that you’ll often discover is the hard part. Because Helm made it “dopamine easy” to deploy applications on Kubernetes with an abstraction layer that is so seamless, users were unaware of the consequences. That’s why when things started to unravel and fail, as they most certainly always will with these one-click, easy deployments, it suddenly became clear to many users that they lack understanding of what’s happening under the hood, inside their clusters, to be able to properly troubleshoot the specific issue.
You Win Some, You Lose Some
There’s no doubt that Helm changed the way Kubernetes can be consumed, making it a critical piece to running microservices today. However, it’s not without its challenges.
One of the main issues with getting started with Helm is its complexity (as a product in the Kubernetes ecosystem, we would expect nothing less). It essentially “hides” that it is like three products mashed up into one tool. As an advanced Kubernetes user, it took me about a month to even wrap my head around what Helm actually does and how to use it.
That’s because, as a tool, similar to Kustomize, which is considered Helm’s greatest competitor, you expect it to be focused on a single use case and do that really well. Kustomize, for example, is laser-focused on providing really great YAML templating and injection. Helm, on the other hand, is kind of all over the place in that regard.
In one single tool, it tries to cover packaging artifacts (like the PyPI, Maven or NPM for Kubernetes), a templating language (their very own proprietary templating language on top of Go. That added its own complexity, but we’ll get to that), and the actual deployment and production life-cycle management of your applications. Bottom line: That’s a lot to handle.
The templating language probably adds the most, for lack of a better word, strangeness to the experience. It is completely not native to the Kubernetes ecosystem, and adding if and else commands to manage your YAML files is a very awkward templating experience.
As they say, jack of all trades, master of none, though I wouldn’t be so harsh in Helm’s case because there are certainly many things it does quite well. Yet this holds true for quite a bit of its functionality that can be downright confusing and complex, and even mediocre at worst. Yet there isn’t really another tool that comes even close to solving the level of complexity Helm does for Kubernetes.
Some would say that any time you do anything besides helm install or helm upgrade it’s a roll of the dice on how it will affect your clusters, like rollbacks, for example. Even if a Helm upgrade can be done in a single command for hundreds of different resources, there’s no easy way to know what you’re going to change and how it’s going to break your systems once you deploy. (There’s no Terraform plan, Terraform apply equivalent in Helm.)
A good example, if we go back to the community contributed charts, would be if you choose to deploy Redis with its certified and maintained Helm chart, you could feasibly have your Redis up and running in minutes. Except when it breaks down, it suddenly dawns on engineers that there are 40 different services running auto-magically that they don’t quite understand and don’t know how to troubleshoot. This can get ugly. That’s why it became increasingly clear to professional operations people that helm install is just the first step; the hard part is knowing how to maintain all of the services being deployed to your clusters.
How to Take Helm to the Next Level
Everything above about Helm is said in love, of course, not hate. It really is the tool everyone loves to troll. Eventually, like all Helm users, I think an ideal world would enable all of us to no longer have to cross fingers and sacrifice our children to the Helm gods for fear of repercussions of what will happen in our clusters upon clicking Helm upgrade.
There’s no doubt that a good start would be to have greater observability and understanding of what’s happening inside Kubernetes clusters when using Helm, and even powerful rollback capabilities and failure management.
Another area that could use improvement is translating Helm error codes (known to be notoriously esoteric, even counterintuitive at times) to common issues. Given a failure in Helm, it becomes nearly impossible to understand its root cause.
Therefore, some good practices for optimizing your Helm experience could include having a base chart that will serve as a standardized way for deploying code to production by all teams using Helm in your organization. In this way, the base chart will always inject the most up-to-date values with each update so that all users of the base chart (who regularly update their versions) will gain the benefits of your latest version updates upon their next deployment.
Another good option would be to use other well-maintained tools in the ecosystem, like ArgoCD. While it too has its learning curves, it does provide the benefit of greater visibility and control over Kubernetes clusters.
Lastly, another useful solution would be to try out the open source project, Helm dashboard, that will enhance and optimize the Helm experience and make it more accessible to less sophisticated users. With this OSS dashboard, you gain almost all of the CLI’s capabilities in a simple and intuitive dashboard — why things fail, validations and checks before deploying to production, as well as when new versions are available and safe paths for upgrades (and rollback) — so you can safely manage the life cycle of your Helm charts.
With these best practices or ecosystem OSS tools, you can gain greater manageability and understandability when employing Helm at scale.
To hear more about cloud native topics, join the Cloud Native Computing Foundation and the cloud native community at KubeCon + CloudNativeCon North America 2022 in Detroit (and virtual) from Oct. 24-28.
