Non-TLS metrics port

[tspearconquest]

Is your feature request related to a problem? Please describe.
We want to scrape descheduler's /metrics path with Prometheus, however there currently appears to be no method to configure the TLS certificate for descheduler used on port 10258. Thus, it cannot be made to use anything but the self-signed certificate which changes with each pod restart, and we have no method to provide this certificate to Prometheus nor any method to configure Prometheus to trust the certificate.

Describe the solution you'd like
We would like to see (firstly) the metrics exposed on a separate container port which does not require TLS, for those environments where encryption of the metrics is not a concern.

Secondly, we would like to have a method to configure the TLS certificate used by descheduler so that if an environment needs encryption of the metrics, then it would be possible to provide the CA to Prometheus so that the certificates issued to descheduler (whether self-signed or otherwise) can be trusted by Prometheus.

Describe alternatives you've considered

What version of descheduler are you using?

descheduler version: 0.31.0

Additional context
I checked through the latest helm chart release to see if any method to configure the TLS certificate has been added since 0.31.0 but found nothing, so I believe this is still a missing feature in the latest releases.

[tspearconquest]

An update: after digging through some manifests in the prometheus repo, I did find that I can setup a service monitor resource which supports insecureSkipVerify. Unfortunately, in our environment, we're not running full prometheus, but a stripped down version managed by New Relic, which doesn't add the ServiceMonitor resource API kind to the cluster, so in our setup we don't have the ability to configure this resource for the use-case mentioned above.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[tspearconquest]

/remove-lifecycle stale