Better control over metrics port in SVC

[paulfantom]

I am doing a PoC for running multiple docker registry mirrors on SVC of LB type using this helm chart. During this I run into an issue where registry metrics were available on LB port, which isn't ideal. Since metrics port is required only when ServiceMonitor is enabled it might make more sense to use .Values.metrics.serviceMonitor.enabled for this instead of .Values.metrics.enabled.

Ideally though it would be beneficial to use a PodMonitor instead and not expose this port on SVC at all. However since this would require a bit more changes I am including it in a separate PR available here - #108. If you decide one of those PRs is appropriate, please close the other one (or both :) )

[joshsizer]

@paulfantom I think I understand the issue you are encountering - you would like the option to disable the debug port for when you are deploying a Service of type LoadBalancer.

I agree, this should be configurable through the chart. The docs on this debug server specifically recommend locking down access to it:

Sensitive information may be available via the debug endpoint. Please be certain that access to the debug endpoint is locked down in a production environment. The debug endpoint should not be exposed publicly to the internet. Instead, keep the debug endpoint private or enforce authentication for it.

Ref: https://distribution.github.io/distribution/about/configuration/#debug

I can see a case, however, where a user would want to disable the ServiceMonitor, but keep the port defined for the Service (they want the debug server, but don't need to scrape prometheus metrics). So I don't think we can toggle the Service Port on or off based on .Values.metrics.serviceMonitor.enabled

I like the idea of the user having the option to use either a ServiceMonitor, a PodMonitor (or both? if they really want to), while also having the ability to turn off the metrics Service port. Maybe a value like .Values.service.debug.enabled with a default to true.

Thoughts?