Closed erikgb closed 8 months ago
Thank you @erikgb for this suggestion! I agree that root level kustomization is something we missed in the PoC version. I like your approach and will be happy to graduate the solution and make it more usable for your teams!
Community Note
Description
It seems like the only supported installation method currently is static manifests published as part of releases. While this works for a simple POC, I don't find it optimal for anything more.
This project appears to use the project layout suggested by kubebuilder, which I think is a good thing! ๐I would like to suggest some minor enhancements to better support installation using kustomize. Let me explain:
My team has created and is maintaining a few operators. Most of them are private source, but one is publicly available on GitHub: https://github.com/statnett/image-scanner-operator. This operator is installed in multiple on-prem clusters. To make the installation as simple as possible, we have extended the kubebuilder layout with an "installation" kustomization on the project root. The only responsibility beyond our kubebuilder default kustomization, is to set the correct image to use. Similar to this projects Makefile target producing the release manifests:
https://github.com/google/kube-startup-cpu-boost/blob/c421a4f84641631d5ae3241323e4a5af63dc9731/Makefile#L135-L138
With this project root kustomization, the installation from out on-prem kustomization could be as simple as:
This kustomization will produce the manifests for our default branch, using the latest release image, which is probably not "that" useful without a ref (tag). This is the core of our current on-prem installation:
Note: While others might prefer a Helm chart, we are trying to avoid Helm for various reasons.
WDYT @mikouaj?
References
0000