I'm fairly convinced that helm in production is an anti-pattern. With you instead having all K8s manifests checked into your Git repository with CI/CD to handle any changes.
Helm just has too much auto-magic and remove's one of k8s best features, the git-blame / git-diff for Infrastructure.
I don't understand why this isn't the prevailing philosophy. I'm over here Terraforming helm deployments and having no idea what is actually happening under the covers.
We have our CI run a helm —-dry-run —-debug before the deploy step, so we can see the exact kubernetes resources that are going to be applied. You can even save that as an artifact so you can diff it later.
Helm still saves you an incredible amount of work for setting up all the third party services.
If your team is big enough you can just write your own configs, but that takes a lot of time and often quite a bit of knowledge about the relevant service.
Rollbacks and resource cleanup is not to be underestimated either if you are not getting that from other tools like Argo.
Note: You can still use the Git-centric approach by generating configuration via `helm template`.
I'm convinced that the only reason Helm saves you time with 3rd party services is because 3rd party services only provide Helm chart or don't provide means of deployment to k8s at all.
I've been using kustomize to deploy some things with ArgoCD and it's so much easier. Now, I'm trying to never use helm for 3rd party.
However, for your internal things, Helm is hard to replace. It's easy to start a chart that is capable of deploying most of your internal services, but maintaining it is a nightmare.
Actually, using helm, as in `helm` the binary, directly sounds bonkers to me and I wouldn't wish this upon anyone.
I use Helm only for installing “supporting applications” -elastic searchoperator, jupyterHub, etc. Our normal deployments are standard K8s configs.
These apps use Helm because a lot of the settings are complicated, Co dependent, etc.
Absolutely would not write helm charts from scratch for normal deployments, and if I got these apps in a better format than helm, I’d probably drop it immediately.
It’s the fact that they are complicated which warrants manual configuration. If the org can’t write the configuration, how will they support it when something goes wrong? It’s a problem waiting to happen.
I can't edit this anymore - but to anyone reading, I ought to specify that I do _not_ use Helm directly, only via Flux, our CD tool. It ablates a lot of the issues of dealing with helm charts.
Helm just has too much auto-magic and remove's one of k8s best features, the git-blame / git-diff for Infrastructure.