For me -- as I am outsider -- it's hard to understand all the non-technical arguments and social dynamics.
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.
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