Feature description
Summary
Adds an opt-in autoscaling.enabled value that wires Ray's in-tree autoscaler into the RayCluster spec. Default is off — chart output is byte-identical to today's behaviour for existing consumers.
Changes
chart/values.yaml — new top-level autoscaling: block with enabled, idleTimeoutSeconds, upscalingMode, resources. All defaults preserve today's static-scaling behaviour.
chart/templates/rayservice.yaml — conditional enableInTreeAutoscaling: true + autoscalerOptions block, gated on .Values.autoscaling.enabled.
chart/Chart.yaml — minor bump 0.4.1 → 0.5.0 for the new feature.
README.md — four new rows in the values table documenting the block.
Backwards compatibility
Default autoscaling.enabled: false. Rendered manifests for any existing values file are unchanged — the new conditional emits nothing when disabled.
Test plan
Value and/or benefit
The gap this closes
The chart already exposes worker.minReplicas and worker.maxReplicas, and the README values table labels both "for autoscaling". But the RayCluster template never emits enableInTreeAutoscaling: true, so KubeRay ignores those fields and always deploys exactly worker.replicas count of workers. The result is that setting minReplicas / maxReplicas has no observable effect today.
This PR wires the missing top-level flag through a new autoscaling: values block. When autoscaling.enabled: true: #27
Chart renders enableInTreeAutoscaling: true on the RayCluster spec
KubeRay attaches an autoscaler sidecar to the head pod
The already-existing worker.minReplicas and worker.maxReplicas become the scaling range
autoscalerOptions.idleTimeoutSeconds and .upscalingMode are configurable via the new block (defaults per Ray docs: 60 s and Default)
Real-world motivation
We hit this while sizing a Ray cluster for a Nebari deployment. The user needed 3+ CPUs on the Ray cluster (checkmaite reserves CPUs for its registry + per-job controller actors before any worker task can be placed). Static bump of worker.replicas unblocked them, but keeping 4 worker pods running 24/7 is wasteful when the cluster is idle. Autoscaling with minReplicas: 1, maxReplicas: 6 would let workers scale to zero-of-what's-needed when the cluster is quiet and up to 6 during active use.
Anything else?
No response
Feature description
Summary
Adds an opt-in autoscaling.enabled value that wires Ray's in-tree autoscaler into the RayCluster spec. Default is off — chart output is byte-identical to today's behaviour for existing consumers.
Changes
chart/values.yaml — new top-level autoscaling: block with enabled, idleTimeoutSeconds, upscalingMode, resources. All defaults preserve today's static-scaling behaviour.
chart/templates/rayservice.yaml — conditional enableInTreeAutoscaling: true + autoscalerOptions block, gated on .Values.autoscaling.enabled.
chart/Chart.yaml — minor bump 0.4.1 → 0.5.0 for the new feature.
README.md — four new rows in the values table documenting the block.
Backwards compatibility
Default autoscaling.enabled: false. Rendered manifests for any existing values file are unchanged — the new conditional emits nothing when disabled.
Test plan
Value and/or benefit
The gap this closes
The chart already exposes worker.minReplicas and worker.maxReplicas, and the README values table labels both "for autoscaling". But the RayCluster template never emits enableInTreeAutoscaling: true, so KubeRay ignores those fields and always deploys exactly worker.replicas count of workers. The result is that setting minReplicas / maxReplicas has no observable effect today.
This PR wires the missing top-level flag through a new autoscaling: values block. When autoscaling.enabled: true: #27
Chart renders enableInTreeAutoscaling: true on the RayCluster spec
KubeRay attaches an autoscaler sidecar to the head pod
The already-existing worker.minReplicas and worker.maxReplicas become the scaling range
autoscalerOptions.idleTimeoutSeconds and .upscalingMode are configurable via the new block (defaults per Ray docs: 60 s and Default)
Real-world motivation
We hit this while sizing a Ray cluster for a Nebari deployment. The user needed 3+ CPUs on the Ray cluster (checkmaite reserves CPUs for its registry + per-job controller actors before any worker task can be placed). Static bump of worker.replicas unblocked them, but keeping 4 worker pods running 24/7 is wasteful when the cluster is idle. Autoscaling with minReplicas: 1, maxReplicas: 6 would let workers scale to zero-of-what's-needed when the cluster is quiet and up to 6 during active use.
Anything else?
No response