The Kubernetes Kustomize KEP Kerfuffle

That's one of my favorite things about that composability of the Kubernetes tools. I don't believe there's a reason for a "tool fight" in the Kubernetes ecosystem. There might be disagreements about best practices, for example how to manage code in a cluster (gitops vs kubectl apply vs helm install vs ...), but that's not a tool fight as much as a methodology difference. And there's room for more than one pattern to emerge.

I think that any tool that is able to deploy an open source project to my cluster, while minimizing the amount of operational overhead I need to assume, is the tool that I want. I don't care if that is Kustomize, Helm, Ksonnet, or anything else, as long as it mets the requirements of a) it has to work with my environment and b) it shouldn't introduce unecessary operational overhead.

You also mention that Kubernetes is hard to learn, which is absolutely a problem. Adoption is growing, but it's getting harder to learn as more features get merged in. And you are right, nobody should have to learn Kubernetes YAML to deploy a standard, off-the-shelf Wordpress installation. But what about more complicated software that needs "last mile" customization done to work in a specific environment? This blog post (https://testingclouds.wordpress.com/2018/07/20/844/) shows a great way to combine the power of the Helm community and chart format with the last-mile tooling that Kustomize can provide to help keep charts simple but still flexible. That feels much better than forking the chart and maintaining a separate copy of it just to make a few changes that are specific to a single use case.

I have mixed feelings about Kustomize getting merged into kubectl. I don't like the idea of Google "crowning" a winner, and I hope the sig-architecture group and Google teams remain diligent to prevent that from happening. Kustomize is not a replacement for Helm, it's a very good tool to handle specific use cases that often involve Helm charts at the source.

From technical point of view, I really like the composition-based/declarative approach of Kustomize.

I am testing different type of bigdata clusters in k8s (Hadoop, Hdfs, Spark, HBase, Hive, Ozone, etc.). I need a method to easily create/install different type of clusters with a set of predefined components. Sometimes I need Spark, sometimes not. Sometimes I need HDFS HA sometimes not. With or without kerberos.

With Helm chart it's almost impossible: all the charts would be full with different conditional branches and which hard to be maintained (and hard to handle dependencies: for example if both hdfs/yarn cluster would like to add something to the core-site.xml configuration).

The composition based approach works better for my use-case, but I found Kustomize very difficult to use. It has strict opinion/limitation how the thing should be defined/worked [1], which are very smart, but sometimes not for my use-case. Also it requires very verbose configuration.

Finally I just created my tool which is more flexible (shameless plug, it's here: [2]) which can do anything with the help of composition and more easy to use.

I respect the Kustomize developers and development and I am very happy that it exists. (And I know that it's way more mature/smart than my tiny tool)

I am just not sure if it it's possible to cover all the use-cases (or majority of the use-cases) with one existing tool (neither with Helm nor with Kustomize). Therefore I would prefer to keep all these tools in separated repo. Personally I would prefer to have more similar tools with new ideas and prefer to have better and better (and more flexible) Kustomize.

But this is just my personal preference.

[1]: https://github.com/kubernetes-sigs/kustomize/blob/master/doc...

[2]: http://github.com/elek/flekszible