I have been using the Kubernetes and Helm for a while and have now come across Kustomize for the first time.
But what exactly is the difference between Kustomize and Helm?
Are both simply different solutions for bundling K8s elements such as services, deployments, ...? Or does it make sense to use both Helm and Kustomize together?
The best way to describe the differences is to refer to them as different types of deployment engines. Helm is a Templating Engine and Kustomize 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 filters 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.
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.
The latter method allows you to scale your configurations to large numbers of variants more easily. Imagine maintaining 10,000 different sets of 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.
Another nuance to make note of is ownership of the projects. Helm is operated by a third party. Kustomize is developed directly by the Kubernetes team. Though both are CNCF projects. In fact, Kustomize functionality is directly supported in Kubectl. You can build and perform a Kustomize project like so: kubectl apply -k DIR. However, the version of kustomize embedded in the kubectl binary is out of date and missing some new features.
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.
The following links were added in the comments below for more comparisons: