prometheus-operator
Add operator sub-command to print the Kubernetes Custom Resources
Component(s)
No response
What is missing? Please describe.
I would like the idea, if the prometheus-operator could print the own CRDs corresponding to own version. The would lead into easier and automated installation, like I got it from velero right now, e.g. /velero install --crds-only --dry-run -o yaml | /tmp/kubectl apply -f -
Describe alternatives you've considered.
Manually scrape the CRDs from the repository
Environment Information.
Environment
Kubernetes Version: Prometheus-Operator Version:
Not sure, since CRDs are bound the prometheus-operator version and poctl uses a different version schema. I would agree, if poctl and prometheus-operator where bundled together, similar to velero where the velero cli contains server and client part in one single binary.
@jkroepke poctl is pulling CRDs from prometheus-operator we just need to make sure whenever we release a new version of Prometheus Operator POCTL is directly updated.
wdyt?
If POCTL and prometheus-operator shares the same version, OK. Otherwise it's terrible to identity which poctl version includes which prometheus-operator CRD version.
Alternately, the prometheus-operator docker images always embedded the correct poctl version.
Context: https://github.com/prometheus-community/helm-charts/pull/5175
Nowadays poctl is an stand alone version, but we can make the prom operator version a flag, by default it will use the one attached to the release, but users could eventually change it through flags wdyt?
wdyt?
If you really ask me, I would give-up the idea of an separate standalone tool with a dedicated versioning. I personally prefer it like kubernetes where kubectl follows the same schema as the backend part or like velero where one monolithic binary handle server and client.
but users could eventually change it through flags
Does include poctl all CRDs versions? I guess no and if the user specify a different version through an flag, poctl may invoke network calls. Such network calls does not work in restricted environments.
In prometheus-community/helm-charts#5175, we provide Helm chart users with a job that updates the CRDs. It's a self-contained process.
In restricted environments, Helm charts and images can be stored in OCI registries. As a kube-prometheus-stack maintainer, I only need to determine the latest Prometheus Operator version. Based on that, the corresponding CRD files can be fetched and included in the Helm chart.
Later, this process will be automated via Renovate. However, Renovate will never know which version of poctl contains the correct CRDs for the corresponding Prometheus Operator version.
I respect the decision to have a dedicated client binary with a separate versioning scheme, but it does not fit my use case.
When I created the issue, my hope was that the Prometheus Operator server binary would gain a subcommand to print the corresponding CRDs, e.g., prometheus-operator print-crd | kubectl apply -f -. Alternatively, including the CRD files as-is in the operator container would also solve the use case for kube-prometheus-stack. Anything else feels too complicated.
It should possible to embed the CRD manifests into the operator binary without too much hassle (https://pkg.go.dev/embed). My only concerns would be
- the size increase of the binary but if we're talking about a few percents, it would be fine.
- the additional complexity in the build process.
@jkroepke thanks for explain detailed your use case, makes sense to me the reason of having embedded CRDs, besides the binary size that would increase as mentioned by @simonpasquier I'm mostly fine on embedding CRDs, we will problably increase by a few mega bytes only