Kubernetes

503 readers

1 users here now

Welcome to Kubernets community. The CNCF graduated project.

founded 4 years ago

MODERATORS

RawHawk@lemmy.ml

Helm feels utterly broken, am I the only one? (lemmy.ml)

submitted 2 years ago by zephyrvs@lemmy.ml to c/kubernetes@lemmy.ml

3 comments fedilink hide all child comments

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!

top 3 comments

sorted by: hot top controversial new old

[–] chonkyninja@lemmy.world 1 points 1 month ago

Kustomize!

[–] procesd@lemmy.world -1 points 2 years ago (1 children)

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.

[–] chihuamaranian@lemmy.ca 2 points 2 weeks ago

Im not the one you replied to, but I wish I had this experience.

I have a k3s install on my homelab, and every helm chart I come across has some new set of assumptions about my cluster baked in and there are often at least one misconception breaking the ability to simply use the helm chart as-is.

Whether its storage container classes, some default ingress config, or something else entirely, I find that the best case is that I write so much yaml into the helm chart I might as well have written the entire thing myself, or it straight up doesn't work (and I then write custom yaml myself anyway)

However, I have enough applications I've converted from app specific installation guides (either assuming bare metal or docker compose) that I've extracted patterns that work for my cluster into a basic template I use.

I clone the template, change the app name, add/delete a few parts as needed for the app, and I commit a copy of it into my argoCD directory that deploys out to the cluster.

Its declarative, and that counts for a lot. But its not very encapsulated.

I dunno, maybe I'm just using it wrong. I'm self taught and this isn't part of my day job. But I haven't experienced helm as "just works" at all.