What is the difference between Helm and Kustomize?
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.
Both has its Pros and Cons. Lets look in this table
Helm is particularly useful for packaging, porting and installing apps that are well-defined, while Kustomize works best for modifying existing Kubernetes apps.
The fact that Kustomize and Helm offer unique specific benefits the best course of action would be to use the two tools side by side.
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 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. 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:
- https://medium.com/@alexander.hungenberg/helm-vs-kustomize-how-to-deploy-your-applications-in-2020-67f4d104da69
- https://codeengineered.com/blog/2018/helm-kustomize-complexity/