-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decouple custom resource config with kube-state-metrics deployment #2050
Comments
Thanks for coming up with a possible solution here @CatherineF-dev @chrischdi I feel like this approach definitely improves the situation, coming with a drawback of added complexity to kube-state-metrics which might make it more difficult to maintain though. I would prefer a solution that mimics a similar design as prometheus and prometheus-operator. This will reduce complexity and simplify things, as well as follow the unix philosphy "Make each program do one thing well". kube-state-metrics-operator could support two CRDs:
A couple of use cases:
What do you think? |
I think we can split it into kube-state-metrics and kube-state-metrics-operator in the future if it's needed. Because
One possible plan is:
Given kube-state-metrics-operator is a breaking change, we can migrate CustomResourceMonitor CRD into kube-state-metrics-operator in v3.x |
Could you elaborate why you think kube-state-metrics-operator is a breaking change to kube-state-metrics? I would have assumed the operator is maintained in a separate repository, similar to https://github.com/prometheus-operator/prometheus-operator and https://github.com/prometheus/prometheus - completely decoupled. This would allow to work independently on it, be on different release cycles. |
I thought |
Ah understood. Let me explain this better: |
Okay, I think both KubeStateMetrics and auto-sharding should be moved into kube-state-metrics-operator. So that kube-state-metrics-operator responsibility is managing pods. CustomResourceMonitor is similar with other metrics, which maybe can be kept in kube-state-metrics. So that kube-state-metrics responsibility is collecting metrics. |
Some perspectives I hope are helpful in deciding where to put this feature.
For these reasons, CRDs should be the first class API for configuring custom resource monitoring. I wouldn't want to have to deploy an entire separate operator pod (wasting resources) just to get a friendly UX. |
/assign @CatherineF-dev |
This issue has not been updated in over 1 year, and should be re-triaged. You can:
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/ /remove-triage accepted |
This will be covered as part of kubernetes/enhancements#4785. |
What would you like to be added:
Why is this needed:
Add a custom resource metric requires changing KSM deployment.
In a company with platform monitoring team and application team, it means application team needs to change codes managed by platform monitoring team.
Describe the solution you'd like
#2049
Additional context
The text was updated successfully, but these errors were encountered: