I’ve been working with Kubernetes since 2015 and I’ve mangled with handcrafted manifests including almost duplicate manifests for staging/production environments, played around with stuff like Cue, built lots glue (mostly shell script) to automate manifest-handling and -generation and I also enjoy parts of Kustomize. When Helm started to appear it seemed like a terrible hack, especially since it came with the Tiller-dependency to handle Helm-managed state-changes inside of the clusters. And while they dropped Tiller (thankfully), I still haven’t made my peace with Helm.
Go-templating it awful to read, a lot of Helm charts don’t really work out of the box, charts can be fed values that aren’t shown via helm show values ./chart, debugging HelmChart $namespace/$release-$chartname is not ready involves going over multiple logs spread over different parts of the cluster and I could go on and on. And yet, almost every project that goes beyond offering Dockerfile+docker-compose.yaml just releases a Helm Chart for their app.
Am I the only one who is annoyed by Helm? Have I been using it wrongly? Is there something I’ve been missing?
In case you’re a Helm maintainer: Please don’t take it personally, my issue is not with the people behind Helm!
I also hate how opaque Helm is. Once things go wrong, it’s pretty challenging to debug. And there is a ton of corner cases around second-day activities (like upgrades or uninstalls) that you need to know about. Good luck if you need to deal with CRDs, or if your chart had resources that are no longer supported in the current version of Kubernetes and you cannot easily upgrade, etc. Helm chart quality (and their documentation) also varies wildly.
I wouldn’t call Helm “utterly broken”, but it does feel like a beta-quality very sharp tool to me; it’s definitely not as plug-n-play as it’s often presented.
“utterly broken” is a bit much, you’re right. I may have a tendency to overuse adjectives. 😎
I like helm and I think the main reason is that I have way less exposure to helm internals than you.
Helm seems to be designed to follow the write-once-apply-everwhere principle. My experience is
- find a promising k8s tool
- get the chart
- read the values file
- apply (as a flux helm release object)
I almost never need to untar and check the templates, helm for me is an easy to use high level abstraction.
I guess that’s why they sell it as a package manager. The experience of writing the chart sounds dreadful, but using it is mostly trivial.
I have only used maybe half a dozen upstream charts (mostly packaged by bitnami but some also by the upstream developers directly) and I have had to untar and check the templates half a dozen times already because of bugs in those charts.