google / kube-startup-cpu-boost

Kube Startup CPU Boost is a controller that increases CPU resource requests and limits during Kubernetes workload startup time
Apache License 2.0
271 stars 14 forks source link

Support installation using kustomize #19

Closed erikgb closed 8 months ago

erikgb commented 9 months ago

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:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - https://github.com/statnett/image-scanner-operator.git

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:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  -  https://github.com/statnett/image-scanner-operator.git?ref=v0.6.32

Note: While others might prefer a Helm chart, we are trying to avoid Helm for various reasons.

WDYT @mikouaj?

References

mikouaj commented 9 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!