(Not that I haven't had the need, I've use jsonnet with libk8s at scale. But if you're asking the question this simply, you probably don't need it)
I brought up envsubst because it’s a simpler, cleaner, and often overlooked option for variable substitution.
> Not that I haven't had the need, I've use jsonnet with libk8s at scale. But if you're asking the question this simply, you probably don't need it
In my view, Jsonnet isn’t an improvement - it’s complicated to learn, cumbersome to use, and prone to mistakes.
That said, if an organization decides to adopt any specific tool, I believe consistency in tooling, design, and practices is more important than the tool itself.
For complex stuff I write Python or Go programs to build manifests, then shell out to kubectl apply. An old example - deploying a multi-instance modded Arma 3 server on k3s: https://github.com/dharmab/homelab-k3s/tree/main/lab
T.b.h. if I were to write a manifest generator, I would still probably commit the thing into a repo and let argo do the rest. Maybe even fiddled around to make the generator into a config-management-plugin ... but that feels like over-doing it.
I'm currently looking at Helmfile so that I don't need to aggregate charts into a 'parent chart', and i'd also like to move towards a single standardised chart that all microservices can use, rather than spin up a new chart for each service.
i like generating k8s yaml with cue, example: https://github.com/cue-labs/cue-by-example/tree/main/003_kub...
there's also https://timoni.sh/ if you want a helm-like experience, but with cue instead of templating.
If you're working with upstream projects, unfortunately many of them will only provide helm charts, so you got to decide between rewriting them to suit your env/tool, or just live with the crappiness of helm.
works really well
