Broadcom to discontinue free Bitnami Helm charts

I’ve never used Helm charts. I learned K8S in a shop in which kustomize is the standard and helm is a permitted exception to the standard, but I just never felt any reason to learn helm. Am I missing out?

Sometimes the limitations of kustomize annoy me, but we find ways to live with them

I wouldn't say you're missing out. If kustomize works for you, keep using it. I personally use helm because I cannot for the life of me wrap my head around kustomize. I've looked at tutorials, read the docs, and it just doesn't make sense to me. Helm, on the other hand, immediately clicked and I was able to pretty effortlessly write charts for our use. It's just a case of different preference in tools, imo.

Helm gives you more than enough rope to hang yourself with. At $dayjob we barely use 3rd party helm charts, and when we do we eventually run into problems with clever code.

We do package our own helm charts, not in the least because we sign contracts with our customers that we will help them run the software we're selling them. So we use package docker and helm artifacts that we sell in addition to running locally.

So we write some charts that don't use most helm features. The one useful thing about Helm that I don't want to live without is the packaging story. We seem to be the only people in the ecosystem that "burn in" the Docker image sha into the Helm chart we package, and set our v1.2.3 version only on the chart. This means we don't have to consider a version matrix between our config and application. Instead we just change the code and config in the same git sha and it just works.

Kustomize feels like less of a hack to me, without the gotpl madness, but it’s way more painful to get something done in my experience. I’ve landed on just writing real code to craft the objects I want (using the actual types, not text), if I absolutely can’t get by with static manifests.

Would you like to count the number of spaces that various items in your manifests are indented and then pass that as an argument to a structure-unaware text file templating engine? Would you like to discover your inevitable yaml file templating errors after submitting those manifests to the cluster? Then yes, you are really missing out!

The main advantage of helm in my experience is:

1. having the ability to create a release artefact helm chart for a version, and store that artefact easily in OCI repositories. 2. being able to uninstall and install a chart and not have to worry about extra state. Generally in Kustomize people just keep applying the yaml and you end up in a state where there’s more deployed than there is in the kustomize config

Some people like that Helm:

- Makes it possible to go from zero to fully running k8s integrated components in 5 seconds by just running 'helm install --repo https://example.com/charts/ mynginx nginx' (very useful: https://artifacthub.io/)

- Gives the ability to transactionally apply k8s configs, and un-apply them if there is a failure along the way (atomic rollbacks)

- Stores copies/versions/etc of each installation in the server so you have metadata for troubleshooting/operations/etc without having to keep it in some external system in a custom way.

- Allows a user who doesn't know anything about K8s to provide some simple variables to customize the installation of a bunch of K8s resources.

- Is composeable, has templates, etc.

So basically Helm has a lot of features, while Kustomize has... one. Very different purposes I think. You can also use both at the same time.

Personally I think Helm's atomic deployment feature is well worth it. I also love how easy it is to install charts. It feels a bit like magic.

One thing I haven't seen mentioned in comment. Dunno if Kustomize has something here. But: Helm is a shit but at least some kind of composition tool. Some way to have resource of various types associated to some top level idea.

Very very little else seems to bring this basic sense to Kubernetes. Metacontroller kind of could do that. Crossplane's whole business is this, but it's been infra-specialized: but the Crossplane v2.0 release is trying to be much more generally useful. https://docs.crossplane.io/v2.0-preview/whats-new/ . Would love other examples of what does composition in Kube.

I really, really, wish we could move away from yaml for tools like this.

> zero to fully running (...) in 5 seconds by just running helm install

Realistically, a plain helm install without any values rarely if ever gives you the deployment you need, so you have to study the chart anyways.

> rollback on failure

This is hardly unique to helm.

> history metadata without (...) some external system

In 2025 you should probably be using gitops anyways, in which case the git repo is your history.

If YAML is a foot-gun, templated YAML is a face-cannon.

Kustomize is nice but you’re missing out on objects lifecycle management.

Kustomize had the issue that it would leave objects dangling in the cluster and you had to manually clean them up of you removed them from your kustomization file.

A couple of years ago I was using https://kapitan.dev/ which I found really good at the time when using jsonnet files to generate the configs. I haven't used it for some time though.

I never understood why people didn’t serialize from JSON if they run a transformation step on the YAML anyway. Read JSON, alter in your favorite language, dump YAML as the last step, deploy. Instant prevention of a lot of sadness.

Yet somehow, all we have is YAML templating?

What do you mean by atomic deployment? There are no transactions in the Kubernetes API. Helm has to make one request for each object it creates or modifies, like any other client.

We just set chart version equal to image version, they live in the same repo and are released and built together (and the chart is only published after successfully publishing the image, so it's always valid). The chart allows to override the image version but we almost never do that, it's for emergencies.

Replacing with hash is a neat idea, might start doing that too.

Kubectl will handle JSON without converting it to YAML. So if you are doing this, then just do kubectl apply -f deployment.json

If you use the kustomize controller from the FluxCD project, you can set it to prune unmanaged objects.

In true GitOps, I think it's should be default on.

> a plain helm install without any values rarely if ever gives you the deployment you need

works for me most of the time

> This is hardly unique to helm.

So what? The guy was asking what is nice about Helm vs Kustomize. Does Kustomize have rollbacks?

> In 2025 you should probably be using gitops

Gitops is literally just "hey I have some configs in Git and I run some command based on a checkout", i.e. infrastructure as code in a git repo. Gitops does not track live server metadata and deployment history. I don't get why people over-inflate this idea.