1. YAML string templating makes it very easy to get indentation and/or quotation wrong, and the error messages can easily end up pretty far from the actual errors. Structured data should be generated with structured templating.
2. "Values" aren't typechecked or cleaned.
3. Easy to end up in a state where a failed deploy leaves you with a mess to clean up by hand.
4. No good way to preview what a deploy will change.
5. Weird interactions when resources are edited manually (especially back in Helm 2, but still a thing).
6. No good way to migrate objects into a Helm chart without deleting and recreating them.
7. Tons of repetitive boilerplate in each chart to customize basic settings (like replica counts).
It's a typical Go solution, in all the wrong ways.
It's not going to solve all your problems but dhall can fix your first few gripes. I've been using it for several months and it's an excellent way to write configuration imo.
Yeah, I have used Nix to generate them in the past, which worked pretty great too. But Helm does, admittedly, solve a real problem: garbage collecting old resources when they're deleted from the repo. I just wish we could have something much simpler that only did that...
`kubectl apply --prune` should nominally do this. Irritatingly (I acknowledge I'm almost as responsible as anyone else for doing something about this), it's had this disclaimer on it for quite some time now:
> Alpha Disclaimer: the --prune functionality is not yet complete. Do not use unless you are aware of what the current state is. See ⟨https://issues.k8s.io/34274⟩.
I haven't used it in anger, so I can't add any disclaimer or otherwise of my own.
kpt is the recent Google-ordained (AFAICT) solution to this problem, but is ot yet at v1.
You could also resolve this yourself by either:
* versioning with labels and deleting all resources with labels indicating older versions
Not the OP, but..
1. YAML string templating makes it very easy to get indentation and/or quotation wrong, and the error messages can easily end up pretty far from the actual errors. Structured data should be generated with structured templating.
2. "Values" aren't typechecked or cleaned.
3. Easy to end up in a state where a failed deploy leaves you with a mess to clean up by hand.
4. No good way to preview what a deploy will change.
5. Weird interactions when resources are edited manually (especially back in Helm 2, but still a thing).
6. No good way to migrate objects into a Helm chart without deleting and recreating them.
7. Tons of repetitive boilerplate in each chart to customize basic settings (like replica counts).
It's a typical Go solution, in all the wrong ways.