[techntoke]

Once you start to see both Kustomize and Helm as a templating language, then you'll realize that Kustomize doesn't cover many use cases and is intentionally limited in scope. There is a reason almost every major project in the Kubernetes ecosystem has a Helm chart, but not a Kustomize configuration file. That doesn't mean that Helm doesn't have it's issues, because their implementation of Go templating is constrained, and Go templating is challenging in itself; however, it does a lot more than Kustomize can offer and covers a significantly larger amount of use cases than Kustomize patch files.

Kustomize is great for getting a job done quickly if you don't mind some duplication of code and effort throughout your projects, but Helm is ideal for managing dependencies and templating across a large amount of projects where you may want to re-utilize other charts.

I think it is ideal to not just discover these tools by reading about them, but actually start using them and spend a few hours trying them out and testing what they can and can't do.

[markbnj]

You're right about these things in my view. There's a lot you can do in a helm chart that you can't do with kustomize and patches. The helm template functions are powerful in their own right; you have conditionals, loops over ranges, you can define your own helpers, and then you have the whole sprig library at your fingertips.

You can't do any of those things with kustomize. And that's really the (admittedly very opinionated) point. I think helm is perfect for the role the project assumed for itself, as a kubernetes package manager. It works well in that role. If you follow the conventions (as you must if you contribute to stable) then your thing has full config coverage with sensible defaults, you can install it multiple times and everything is namespaced.

Like any package manager it's somewhat difficult to write good packages that have all these attributes. And I think you have to admit that a well-written helm chart that covers all the bases is a lot less readable (albeit much more powerful, stipulated) than a simple yaml description of the object you want. It really does constitute a separate API between the developer and the system.

For our own deployable services we don't need all those package manager-like attributes. What we need is for the on-disk representation of our resources to be readable, and we want to be able to make simple changes to single files and not chase value substitution around through layers of indirection. We'll probably continue using helm for stable infrastructure things, but for our own services that are under continuous development and deployment it's come to feel like a mismatch.

[Rotareti]

> Like any package manager it's somewhat difficult to write good packages that have all these attributes. And I think you have to admit that a well-written helm chart that covers all the bases is a lot less readable (albeit much more powerful, stipulated) than a simple yaml description of the object you want.

I agree to that, but I think the situations in which you have to write really flexible and complex charts are pretty rare. Most of the charts that we maintain and use internally, use very little templating, because they are tailored to fit our own environments, not every environment under the sun.

[techntoke]

There are situations where it makes sense to create a shared chart that can be used by multiple teams to implement their services, but to be extensible enough to work with other common services. For example, cert-manager and external-dns. Or for a local environment, you may want to use Minio for AWS-compatible storage but Service Catalog and AWS Service Broker for other environments.