[kube-state-metrics] Default monitor selector using app.kubernetes.io/instance conflicts with ArgoCD

[Stealthmate]

Describe the bug a clear and concise description of what the bug is.

I ran into this with kube-state-metrics, but after looking around it seems like it's probably affecting other components as well.

For kube-state-metrics, the issue is that, by default, the ServiceMonitor selects endpoints based on the app.kubernetes.io/instance label (ref), however ArgoCD overrides that with the app name defined in ArgoCD. In my case, that's not the same as the release name, so the ServiceMonitor breaks.

What's your helm version?

3.8.0

What's your kubectl version?

1.25.0

Which chart?

kube-state-metrics

What's the chart version?

45.9.1

What happened?

No response

What you expected to happen?

No response

How to reproduce it?

Install kube-state-metrics / kube-prometheus-stack with ArgoCD (Helm), set the release name to kube-prometheus-stack and the ArgoCD app name to something else (e.g. my-app).

Enter the changed values of values.yaml?

N / A

Enter the command that you execute and failing/misfunctioning.

N / A

Anything else we need to know?

I can think of two workarounds for this:

1. Change release name in ArgoCD manifest to match with ArgoCD app name
2. Use kube-state-metrics.prometheus.monitor.selectorOverride to set the selector labels manually (<- this is what I did)

I did manage to solve the problem using workaround 2, but I think it would be nice if the chart used different labels by default (it took me a few hours to find the source of the problem). If maintainers agree, I'm willing to push a PR for this, but I think it's important to decide what labels to use so that they don't conflict with other stuff like ArgoCD.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

[mnorrsken]

I just stumbled over the same bug, but I can live with option number 1.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.