[bigstrat2003]

We have several Helm charts we've written at my job and they are very pleasant to use. They are just normal k8s templates with a couple of values parameterized, and they work great. The ones people put out for public consumption are very complex, but it isn't like Helm charts have to be that complex.

[phyrog]

In my book the main problem with Helm charts is that every customization option needs to be implemented by the chart that way. There is no way for chart consumer to change anything the chart author did not allow to be changed. That leads to these overly complex and config heavy charts people publish - just to make sure everything is customizable for consumers.

I'd love something that works more like Kustomize but with other benefits of Helm charts (packaging, distribution via OCI, more straight forward value interpolation than overlays and patches, ...). So far none have ticked all my boxes.

[ranger207]

Yeah too many times the Helm chart is barely less complex than writing all the manifests yourself because all the manifest options are still in the chart

[glotzerhotze]

fluxCD brings a really nice helm-controller that will allow to change manifests via a postRenderers stub while still allowing to use regular helm tooling against the cluster.

https://fluxcd.io/flux/components/helm/helmreleases/#post-re...

[phyrog]

Yeah, but then it is yet another layer of configuration slapped on top of the previous layer of configuration. That can't be the best solution, can it? Same thing for piping helm template through Kustomize.

[maherbeg]

Yeah, this setup is both nice and insane. If you don't need much extra customization it's great. But I have a setup where I needed both postBuild and postRenderer's + actual kustomization layering and it was awful trying to figure out the order of execution to get the right final output.

In hindsight it would have been much faster to write the resources myself.

[nwmcsween]

Use helm to generate the manifests with a Makefile, use Kustomize to change said manifests for prod, staging, etc.

[lillecarl]

Kustomize can render Helm charts. It's "very basic" as in Kustomize will call the Helm binary to render the template, ingest it and apply patches.

I wrote a tool called "easykubenix" that works in a similar way, render the chart in a derivation, convert the YAML to JSON, import JSON into the Nix module structure and now you're free to override, remove or add anything you want :)

It's still very CLI deploy centric using kluctl as the deployment engine, but there's nothing preventing dumping the generated JSON (or YAML) manifests into a GitOps loop.

It doesn't make the public charts you consume any less horrible, but you don't have to care as much about them at least

[honkycat]

Yes, this is the key. Helm charts should basically be manifests with some light customization.

Helm is not good enough to develop abstractions with. So go the opposite way: keep it stupid simple.

Pairing helm with Kustomize can help a lot as well. You do most of the templating in the helm chart but you have an escape hatch if you need more patches.

[cogman10]

That's generally what I try to push for in my company.

A single purpose chart for your project is generally a lot easier to grok and consume vs what can be done.

I think the likes of "kustomize" is probably a more sane route to go down. But our entire infrastructure is already helm so hard to switch that all out.

[Hamuko]

I've personally boiled down the Helm vs. Kubernetes to the following:

Does your Kubernetes configuration need to be installed by a stranger? Use Helm.

Does your Kubernetes configuration need to be installed by you and your organization alone? Use Kustomize.

It makes sense for Grafana to provide a Helm chart for Grafana Alloy that the employees of Random Corp can install on their servers. It doesn't make sense for my employer to make a Helm chart out of our SaaS application just so that we can have different prod/staging settings.

[uf00lme]

This has been my argument for years now.

I think it is because most engineers learn to use Kubernetes by spinning up a cluster and then deploying a couple of helm charts. It makes it feel like that’s the natural way without understanding the pain and complexity of having to create and maintain those charts.

Then there are centralised ‘platform’ teams which use helm to try and enforce their own templating onto everything even small simple micro services. Functionally it works and can scale, so the centralised team can justify their existence but as a pattern it costs everyone a little bit of sanity.

[bigstrat2003]

I'm ashamed to say it but I cannot for the life of me understand how kustomize works. I could not ever figure out how to do things outside the "hello world" tutorials they walk you through. I'm not a stupid person (citation needed lol), but trying to understand the kustomize docs made me feel incredibly stupid. That's why we didn't go with that instead of Helm.

[globular-toast]

Helm requires you to write a template and you need to know (or guess) up front which values you want to be configurable. Then you set sane defaults for those values. If you find a user needs to change something else you have to edit the chart to add it.

With Kustomize, on the other hand, you just write the default as perfectly normal K8s manifests in YAML. You don't have to know or care what your users are going to do with it.

Then you write a `kustomizatiom.yaml` that references those manifests somehow (could be in the same folder or you can use a URL). Kustomize simply concatenates everything together as its default behaviour. Run `kubectl kustomize` in the directory with `kustomization.yaml` to see the output. You can run `kubectl apply -k` to apply to your cluster (and `kubectl delete -k` to delete it all).

From there you just add what you need to `kustomization.yaml`. You can do a few basics easily like setting the namespace for it all, adding labels to everything and changing the image ref. Keep running `kubectl kustomize` to see how it's changing things. You can use configmap and secret generators to easily generate these with hashed names and it will make sure all references match the generated name. Then you have the all powerful YAML or JSON editing commands which allow you to selectively edit the manifests if you need to. Start small and add things when you need them. Keep running `kubectl kustomize` at every step until you get it.

[brainzap]

this, our helm charts are flat and for year only passed in the image as variable