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 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
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.