Comparative Study of JupyterLab Deployment Models: Serverless (Knative) vs. Kubernetes Deployment¶
Author: Michael Pisman
Published: EECS 268, UC Merced, Spring 2025 (unpublished report)
Links: GitHub Repository
Abstract¶
Interactive notebooks are essential for data analysis and teaching, but keeping them running wastes resources when idle. This study compares two deployment models: a serverless approach using Knative Serving and a traditional Kubernetes deployment with JupyterHub. A lean JupyterLab container was built and deployed on a three-node MicroK8s cluster.
Key Findings¶
The Knative serverless deployment achieved:
| Metric | Value |
|---|---|
| Cold-start latency (scale from zero) | 3.19 s |
| Warm-start latency (already running) | 0.13 s |
| Scale-to-zero capability | ✓ |
| Idle resource cost | Zero (pods removed when idle) |
The Horizontal Pod Autoscaler (HPA) used in the traditional Kubernetes model cannot scale to zero, meaning idle pods continue consuming resources until manually cleaned up. JupyterHub with its default KubeSpawner provides good isolation (one pod per user) but maintains those pods even when users are away.
Research Context¶
This study lays the foundation for the CSED Lab's investigation into serverless interactive computing — specifically the idea of a "serverless IPyKernel" that dispatches individual notebook cells to pooled lightweight containers, keeping common libraries warm in memory while storing interpreter state externally. The 3.19-second cold start and 0.13-second warm start demonstrate that Knative-based notebook serving is viable for interactive workloads, and the scale-to-zero property offers compelling cost savings for educational deployments where notebooks are used intermittently throughout the day.