[ctroein89]

Mind expanding a little on your complaints about Helm? I’ve only used Helm as a templating solution (and even then only to differentiate between local, staging and production), so I’m curious what problems I have to guard against.

[joshuak]

Think of Kubernetes like a single application. The config files are the source for that application, the running cluster is the compiled application running on the users computer. By default Helm injects more "compiled" code unrelated to your applications source into the running application. Allowing any tool to alter active cluster state diffuses your single source of truth, your source code, to multiple sources of truth which will not remain in sync with your source unless great care is taken. Moving in sync matters, because that is how you roll back to a known good state when things break.

If you are using Helm to generate source code for your application you still have the added complexity of additional build step, but at least you can choose to add the generated code to your app in a way that tracks with the rest of your code.

Also most Helm chart authors are of varying skill level, and even skilled ones necessarily make incorrect assumptions about your deployment environment. It takes a lot of addition code in helm charts to support more flexibility, so it often get ignored, and you are left with a black box that doesn't quite do what you'd want it to do.