feat(chart): add opt-in enableInTreeAutoscaling support

README.md

@@ -219,6 +219,10 @@ Key values in `chart/values.yaml`:
 | `worker.resources.requests.cpu` | `1` | Worker CPU request |
 | `worker.resources.requests.memory` | `2Gi` | Worker memory request |
 | `worker.runtimeClassName` | - | Runtime class for worker pods (e.g., `nvidia` for GPU) |
+| `autoscaling.enabled` | `false` | Enable Ray in-tree autoscaling of worker pods |
+| `autoscaling.idleTimeoutSeconds` | `60` | Seconds an idle worker is kept before scale-down |
+| `autoscaling.upscalingMode` | `Default` | `Default`, `Conservative`, or `Aggressive` |
+| `autoscaling.resources` | `{}` | Optional resources for the autoscaler sidecar container |
 
 ### Serve Applications
 

chart/Chart.yaml

@@ -2,7 +2,7 @@ apiVersion: v2
 name: nebari-rayserve-pack
 description: A Nebari Software Pack for Ray Serve
 type: application
-version: 0.4.1
+version: 0.5.0
 appVersion: "2.43.0"
 dependencies:
   - name: kuberay-operator

chart/templates/rayservice.yaml

@@ -19,6 +19,16 @@ spec:
 
   rayClusterConfig:
     rayVersion: {{ .Values.image.tag | quote }}
+    {{- if .Values.autoscaling.enabled }}
+    enableInTreeAutoscaling: true
+    autoscalerOptions:
+      idleTimeoutSeconds: {{ .Values.autoscaling.idleTimeoutSeconds }}
+      upscalingMode: {{ .Values.autoscaling.upscalingMode }}
+      {{- with .Values.autoscaling.resources }}
+      resources:
+        {{- toYaml . | nindent 8 }}
+      {{- end }}
+    {{- end }}
     headGroupSpec:
       rayStartParams:
         dashboard-host: "0.0.0.0"

chart/values.yaml

@@ -222,6 +222,52 @@ worker:
     timeoutSeconds: 2
     failureThreshold: 120
 
+# =============================================================================
+# Ray In-Tree Autoscaling
+# =============================================================================
+# Enable Ray's in-tree autoscaler to dynamically scale worker pods based on
+# task demand. When `autoscaling.enabled` is true, the chart:
+#   - Sets `enableInTreeAutoscaling: true` on the RayCluster spec, causing
+#     KubeRay to attach an autoscaler sidecar container to the head pod.
+#   - Uses `worker.minReplicas` and `worker.maxReplicas` as the scaling range
+#     (both fields are already exposed above; without autoscaling enabled
+#     they are ignored by KubeRay).
+#
+# Without autoscaling.enabled the chart is byte-identical to the pre-existing
+# behaviour: worker.replicas is the deployed count, min/max are inert.
+#
+# See the KubeRay autoscaling guide for background:
+# https://docs.ray.io/en/latest/cluster/kubernetes/user-guides/configuring-autoscaling.html
+#
+# Ray's docs explicitly note that autoscaling "adds node launch overheads
+# and can be tricky to configure" — starting with a fixed replica count
+# (autoscaling.enabled: false) is recommended for newcomers.
+autoscaling:
+  enabled: false
+
+  # Time in seconds an idle worker pod is kept alive before being scaled
+  # down. Lower values reclaim resources faster but can create pod churn if
+  # tasks arrive in bursts.
+  idleTimeoutSeconds: 60
+
+  # upscalingMode:
+  #   - `Default`      — standard responsiveness
+  #   - `Conservative` — pending requests scale up in batches on a delay
+  #   - `Aggressive`   — immediately upscale to satisfy demand
+  upscalingMode: Default
+
+  # Optional overrides for the autoscaler sidecar container's resources.
+  # KubeRay's own defaults apply when unset ({}); typical production
+  # override:
+  #   resources:
+  #     limits:
+  #       cpu: "500m"
+  #       memory: "512Mi"
+  #     requests:
+  #       cpu: "500m"
+  #       memory: "512Mi"
+  resources: {}
+
 # =============================================================================
 # Overrides
 # =============================================================================