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!

  • procesd@lemmy.world
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    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.