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