search

adambkaplan / kubebuilder-plus

Experimental improvements on the kubebuilder project layout
Apache License 2.0
0 stars 0 forks source link

Kustomize vs. Helm Charts #2

Open otaviof opened 2 years ago

otaviof commented 2 years ago

Testing out the layout proposed on this project, I notice that kustomize is used extensively to allow on-the-fly modification of the Kubernetes resources. On that note, should we adopt a Helm Chart directly?

For instance, on the image project we have the following construction to overwrite the deployment's fully qualified image name:

helm template \
    --namespace="$(NAMESPACE)" \
    --set="image=ko://github.com/shipwright-io/image/cmd/imgctrl" \
    ./chart | \
        ko apply --base-import-paths --filename -

Considering we would like to offer Helm Charts as a standard way of deploying our applications, I think we should consider using them for the inner loop as well.

WDYT?

adambkaplan commented 2 years ago

+1 to this idea. I'm actually taking a lot of lessons/ideas here to shipwright-io/triggers, currently crafting a PR to boostrap the controllers.

adambkaplan commented 2 years ago

So I've gone down the path of trying to use Helm and Kubebuilder's kustomize-based "inner loop" model. Using kustomize with Helm is doable - JFrog has a great blog post explaining how you can modify Helm charts with Kustomize: https://jfrog.com/blog/power-up-helm-charts-using-kustomize-to-manage-kubernetes-deployments/.

It doesn't appear that you can easily create Helm charts from kustomized manifests, because you lose the ability to embed Helm directives.