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.
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 withconnection 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/clusterandray.io/serveselector. This leaves Helm/Argo CD and KubeRay writing the same resource.Impact
The documented stable Serve endpoint is unreliable for model traffic.
Potential fixes
-serve-svcService and ensure its selected pods run Serve proxies; orEither approach should leave one writer for the Service and include a test that all selected endpoints accept traffic on port 8000.