Almost everything. Like asking what's the difference between Apache and Nginx :) They do vaguely similar jobs but quantifying the differences is kind of impossible.

The short version is that Helm is a template-driven system based on decentralized model for chart sharing. Kustomize is based on deep merges and other structured transforms of YAML data.

There are cases where using both is reasonable, such as feeding the output from helm template into kustomize for overlays.

The best way to describe the differences is to refer to them as different types of deployment engines. One is a Templating Engine and one is an Overlay Engine.

So what are these? Well when you use a templating engine you create a boilerplate example of your file. From there you abstract away contents with known operators and within these abstractions you provide references to variables. These variables are normally abstracted to another file where you insert information specific to . your environment Then, on runtime, when you execute the templating engine, the templates are loaded into memory and all of the variables are exchanged with their placeholders. The resultant file is then saved to disk or processed by an application.

This is different from an overlay engine in a few nuanced ways. Normally about how information gets into configuration examples. Noticed how I used the word examples there instead of templates. This was intentional as Kustomize doesn't use templates. Instead, you create a Kustomization.yml file. This file then points to two different things. Your Base and your Overlays. At runtime your Base is loaded into memory and if any Overlays exist that match they are merged over top of your Base configuration.

This latter schema is better in several ways. Most importantly, it allows you to scale your configurations to large numbers of variants more easily. Imagine maintaining 10,000 different variables files for 10,000 different configurations. Now imagine maintaining a hierarchy of modular and small configurations that can be inherited in any combination or permutation? It would greatly reduce redundancy and greatly improve manageability.

The last important distinction to make, and the one I avoided to make until now, is how the two operate differently. Because that wasn't what your question was necessarily about and it is somewhat of a polarizing topic.

Helm has traditionally deployed applications to your cluster by maintaining a pod with super admin privileges in the cluster called the Tiller. Then you would communicate with the Tiller and this would produce your workloads for you. This is a pretty bad idea because a lot of newcomers to the Kubernetes ecosystem default to using Helm to deploy applications because it automates some serious complexity away. The problem is, people could take advantage of this Black Box scenario but writing malicious code that Tiller then would execute on the naive person's cluster.

Kustomize is different in that it operates more than Helm Template. Rather than interacting directly with the Kubernetes API Server, Kustomize simply merges files and produces output. So, once you have defined all of your bases and patches, you simply run kustomize build and all of the patches will automatically be applied and the resultant patched files will be produced to STDOUT. It is then up to the admin themselves to evaluate the contents of this output to determine whether or not it is accurate. And then commit it to the API Server themselves.

Another nuance to make note of is ownership of the projects. Helm is operated by a third part. Kustomize is developed directly by the Kubernetes team. In fact, Kustomize functionality is directly supported in Kubectl. You can build and perform a Kustomize project like so: kubectl apply -k DIR.

There are a few other improvements in Kustomize too that are somewhat more minor but still worth mentioning. It can reference bases from the internet or other non-standard paths. It supports generators to build configuration files for you automatically based on files and string literals. It supports robust & granular JSON patching. It supports injecting metadata across configuration files.

EDIT: The following content was removed by my answer by another user. I agree that bias was injected here however I still believe the information should be contributed in a paraphrased format rather than outright omitted.

The list goes on Kustomize is clearly the superior project.

I believe that as time goes on Helm will become less and less relevant in the community and people will gravitate more and more towards Kustomize as it continues to mature and maintain more and more official support by the Kubernetes community.

More accurately I meant to imply that as time progresses utilization of Kustomize will surpass that of Helm due to it being developed natively by the Kubernetes team and simultaneously not being plagued by a development history of ignored security concerns.

EDIT 2: It was mentioned that Helm 3 no longer uses Tiller. This is correct, I should have mentioned that on my original post.