Stable Serve Service can route to pods without a Serve proxy

Bug

In a private development environment, the stable Serve Service (<release>-nebari-rayserve-serve-svc) selected every Ray pod, but port 8000 was listening only on pods running a Serve proxy. Requests therefore failed intermittently with connection refused, depending on the selected endpoint.

The pack also renders this Service with a head-only selector, while the KubeRay RayService controller reconciles the same Service name with its own ray.io/cluster and ray.io/serve selector. This leaves Helm/Argo CD and KubeRay writing the same resource.

Impact

The documented stable Serve endpoint is unreliable for model traffic.

Potential fixes

• Let KubeRay exclusively own the canonical -serve-svc Service and ensure its selected pods run Serve proxies; or
• Give the chart-owned Service a distinct name and select only proxy-bearing pods.

Either approach should leave one writer for the Service and include a test that all selected endpoints accept traffic on port 8000.

Start by tracing the chart-rendered stable Serve Service and the KubeRay RayService controller's reconciliation of the same Service name. Choose an ownership or naming approach, then verify that the resulting selector targets only Serve-proxy pods and add the requested test showing all selected endpoints accept traffic on port 8000.