Christian Theilemann
2 min readAug 21, 2018


Well said! I was initially excited about how quick helm hello world examples or apps can be deployed but helm gets really confusing once one wants to bring it to production and use it on a larger scale. I would even go so far that helm has been one of the most confusing tools in the k8s world for me. Given that it’s just being used by almost everyone as a glorified templating CLI it’s really not worth its complexity imho.

Besides the things that you mentioned I generally feel that the terminology chosen for Helm is really poor.
Like wth is a Chart? Can’t you just name it helm package?? In the CLI I invoke helm package and not helm chartify etc..
Why is tiller called tiller — wouldn’t it be better to simply name it helm-release-manager or something along those lines?

Even the choice of the word release for helm is confusing in my opinion. It’d rather call it “rollout” or something similar, because the term release has so many other meanings in software development. Also what means “upgrading a release”(?) and why is there a difference between helm install and helm upgrade (E.g. why is there no idempotent *helm apply* that I can easily use in CI). Oh and when you want to publish your own “chart” you gotta publish it to a “museum”, lol. Perhaps that’s where helm 2 itself belongs :-P

I could go on, but in general I feel the naming and abstractions in helm are pretty poor. I’m a big fan of boring, meaningful names in Software Engineering and not giving every single mini component some random name that doesn’t explain how the components relate to each other. Helm feels like the opposite of that philosophy.

I also had very similar experiences when evaluating It doesn’t suffer from so many weird names, but still some concepts / abstractions are not clear. For example why does every invocation of brigade run have to be linked to a repository and a helm release, even when i’m passing the full, self contained pipeline definition in a file already? Why is the brigade dashboard called “Kashti” instead of just Brigade UI or Dashboard? My company is meanwhile using argo (alternative to brigade) which is built by Jesse Suen and co, and the abstractions and namings there are much more clear. The core workflow framework is called argo and there’s there’s additional (optional!) components like argo-ui, argo-cd, argo-events and argo-ci which are loosely built around the core with clear separation of concerns.

I think helm 3 getting rid of tiller is already an important milestone, but I hope that they also manage to streamline general separation of concerns, package lifecycle (or should i say chart?) and de-confuse the whole terminology, CLI commands etc.