JupyterHub Kubernetes Autoscaler

JupyterHub gives users interactive notebook environments, and a busy service may need more machines as people start sessions. This historical autoscaler adjusted cluster capacity around that workload, using memory and utilization settings to decide when to grow or shrink. It was intended to support notebook availability rather than simply add application replicas. The controller is archived, so existing deployments should map its capacity assumptions to current JupyterHub and cloud node-scaling mechanisms.

Current guidance

This record identifies the former data-8/autoscaler, now at berkeley-dsep-infra/autoscaler. GitHub marks that exact repository archived. It implemented node scaling for JupyterHub using memory requests, utilization thresholds and labels; it is not the current JupyterHub Helm chart or Kubernetes’ general cluster autoscaler.

Current Zero to JupyterHub guidance describes autoscaling node pools, user scheduling, placeholder pods and image pre-pulling. Those features coordinate capacity and notebook startup, but they are not a renamed release of the old controller. Map the old minimum and maximum nodes, omitted namespaces and critical-pod assumptions to the target cloud and current chart configuration.

Notebook users often hold state in memory, so test how idle culling, node drains and interrupted sessions interact with persistent user storage. Tune resource requests using actual notebook workloads rather than copying an example users-per-node figure. Verify a burst of logins, image-pull delay and a scale-down while users are active. Remove competing node-scale controllers only after confirming which component owns desired capacity and that recovery behavior is acceptable.