[buster]

There is a helm provider. Why would you need it? Can't you just use the kubernetes provider?

People probably don't realize, that helm mostly is templating for the YAMLs kubernetes wants (plus a lot of other stuff that increases complexity).

[vbezhenar]

There are many applications which are distributed as helm charts. Those charts install multiple deployments, service accounts and whatnot. They barely document all these things.

So if you want to avoid helm, you gotta do a whole lot of reverse-engineering. You gotta render a chart, explore all the manifests, explore all the configuration options, find out if they're needed or not.

An alternative is to just use helm, invoking it and forgetting about it. You can't blame people for going the easy way, I guess...

[darkwater]

Yep, this 100%. Every time there is a technology which has became the "de facto" standard, and there are people proposing "simpler alternatives", this is the kind of practical detail that makes a GIANT difference and that's usually never mentioned.

Network effect is a thing, Helm is the de facto "package manger" for Kubernetes program distribution. But this time there are generally no alternative instructions like

  tar xzf package.tar.gz; ./configure; make; adduser -u foo; chown -R foo /opt/foo

[buster]

I think we are having different contexts here. I am mostly talking about selfwritten services and how writing, maintaining and deploying helm charts for them is a nightmare.

Regarding dependencies: Using some SaaS Kubernetes (Google GKE) for example, you'll typically use terraform for SQL and other Services anyway (atleast we do use Google CloudSQL and not some selfhosted postgres in k8s).

I find it interesting that cert-manager points to kubectl for new users and not helm: https://cert-manager.io/docs/installation/

But, for sure, there may be reasons to use helm, as you said. I'm sure it is overused, though.

[uf00lme]

It might feels natural to try and use terraform to deploy kubernetes resources since you’ve likely configured the cluster using it, but the helm/kubeneters/kubectl providers are limited by terraform’s way of working. So whilst the providers try to marry the two when deploying anything complex it generally ends up feels like a hack and you lose a lot of the benefits of using terraform in the first place.

In my experience, it’s best to bootstrap ArgoCD/flux, rbac and cloud permissions those services need in Terraform and then move on to do everything else can via Kustomize via gitop. This keeps everything sane and relatively easy to debug on the fly, using the right tool for the job.

[shagmin]

I know at least a couple times just the templating side saved me where it was convenient to just run a helm command with --dry-run to get the yaml and grab & modify the relevant pieces and apply those manually where I don't necessarily want the whole package or I want snippets of a package or modified yaml that their helm chart didn't support out of the box, etc.,.

[Traubenfuchs]

Have you seen ingress-nginx.yaml? It's like 1000 lines with only a few cloud-provider specific changes. Managing and updating that manually with pure kubernetes sucks.