-
Notifications
You must be signed in to change notification settings - Fork 688
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
Allow separate listeners for metrics and healthchecks #2380
Comments
@jedsalazar What is your goal here? When you say you are trying to protect endpoints, can you clarity the policy that you would like to implement? How would having /ready and /stats on different ports help you? |
@jpeach the goal is to bind /metrics to a discrete port which would disallow anonymous access to metrics endpoints by using kube-rbac-proxy for the specified /metrics port. |
Calico has implemented similar functionality. This refers to similar functionality to their "FELIX_PROMETHEUSMETRICSHOST" and "FELIX_PROMETHEUSMETRICSPORT" options. |
That makes sense, retitling for clarity. The ask here is for operators to be able to specify separate listeners for the health check and metrics services. This will involve changing the command line flags and the deployment YAML, and considering how backwards compatibility can be supported. |
Beginnings or draft design doc |
@pickledrick I think a design doc is fine, but for this, I'd recommend we just expose additional args to The default should be to keep the current behavior consistent. |
This provides the ability to separate the HTTP listeners for the health and metrics services. Both address and port are configurable for each service. Defaults are maintained to support backward compatibility. This fixes #2380. Signed-off-by: Peter Grant <pegrant@vmware.com>
Please describe the problem you have
We understand that Envoy will listen on 8002, both /ready and /stats/* endpoints get presented through here. It is /stats (and everything else under /stats/*) that we need to protect, but not /ready.
Our Contour/Envoy configuration requires /ready must be HTTP and not HTTPS due to #1503, and it has to be unprotected so load balancers can query it.
We looked at the Prometheus.io annotations in the Envoy deployment spec, but this does not seem to do anything.
Tried to configure the Prometheus stats address/port as command line arguments to contour. Specifically, something like:
--stats-address=0.0.0.0 --stats-port=8003
Unfortunately the flag did not work. /ready and /stats are stilled tied together after bouncing Contour and Envoy, and I believe this to be hard-coded.
If we look up "statsPort", we can find it here: https://github.com/projectcontour/contour/blob/v1.2.1/cmd/contour/servecontext.go#L121
We see it used here, creating a new listener: https://github.com/projectcontour/contour/blob/v1.2.1/cmd/contour/serve.go#L184
Which is this function: https://github.com/projectcontour/contour/blob/v1.2.1/internal/contour/listener.go#L213
And finally we see where our listener payload is generated: https://github.com/projectcontour/contour/blob/v1.2.1/internal/envoy/stats.go#L27
It seems /ready and /stats are tied together, and we need these to be separated. I believe we are looking towards a feature request.
The text was updated successfully, but these errors were encountered: