Hacker News new | ask | show | jobs
by phyrog 226 days ago
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.
3 comments
ranger207 225 days ago
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
link
glotzerhotze 226 days ago
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...

link
phyrog 226 days ago
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.
link
maherbeg 225 days ago
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.

link
nwmcsween 223 days ago
Use helm to generate the manifests with a Makefile, use Kustomize to change said manifests for prod, staging, etc.
link
lillecarl 225 days ago
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

link