[SPARK-58691] Allow metrics scraping ingress to SparkCluster worker web port - #794
[SPARK-58691] Allow metrics scraping ingress to SparkCluster worker web port#794yalindogusahin wants to merge 2 commits into
Conversation
There was a problem hiding this comment.
Thank you for making a PR, @yalindogusahin .
However, I'm -1 for this AS-IS PR because 8081 is used for the whole worker UI.
|
Thank you for reviewing and that is correct my bad at all I haven't checked the metric names. However, if we decide to use jmx exporter to expose spark related metrics we should enable this network policy. For the statsd thats not the case I believe. If we decide to go with jmx exporter we should bake jmx exporter to the image itself and + mapping config. |
…d of the shared web UI port
|
Pushed a redesign that addresses this directly: added an optional |
What changes were proposed in this pull request?
This PR adds a second ingress rule to the worker
NetworkPolicygenerated for everySparkCluster, admitting any source on the worker'swebport (8081) — the port thatserves the worker web UI and, when
PrometheusServletis configured viaspark.metrics.conf, the/metrics/prometheusscrape endpoint. The existing rule(cluster label / driver label allow-list, unrestricted ports) is untouched, so RPC,
shuffle, and block-manager ports stay locked down exactly as before.
Why are the changes needed?
The worker
NetworkPolicygenerated inSparkClusterResourceSpec#buildWorkerNetworkPolicyonly admits ingress from pods carrying the cluster label or, since SPARK-58649, the driver
role label. Prometheus scraper pods carry neither, so they're indistinguishable from any
other unrelated pod and are locked out entirely — including from the metrics endpoint,
which is not sensitive and is meant to be broadly scrapable.
Verified against a live cluster running an affected build: with only the pre-fix policy in
place,
curl http://<worker-ip>:8081/metrics/prometheusfrom an unlabeled pod times out.The worker itself serves real metrics fine locally (
PrometheusServletworks as configuredvia
sparkConf); theNetworkPolicyis what blocks the scrape. Masters are unaffectedsince they have no
NetworkPolicyapplied.Does this PR introduce any user-facing change?
Yes. The generated worker
NetworkPolicynow also admits ingress on thewebport fromany source. Since NetworkPolicies are additive this can only widen ingress on that one
port, so it cannot deny traffic that was previously allowed. Clusters running on a CNI that
does not enforce NetworkPolicy are unaffected either way.
How was this patch tested?
Extended
SparkClusterResourceSpecTest#testWorkerNetworkPolicyto assert the new ingressrule (no
fromrestriction, single port namedweb).Both pass.
Was this patch authored or co-authored using generative AI tooling?
Generated-by: Claude Sonnet 5