Starting a Jupyter notebook looks like one click. At roughly 5,000 daily sessions, a GPU-backed server may cross several control boundaries before it is ready. This poster visualizes that path across multiple Kubernetes clusters.

A user selects a profile containing CPU, memory, GPU, image, and storage requirements. A multi-cluster KubeSpawner converts it into Kubernetes resources and manages the lifecycle across manager and worker contexts. Kueue evaluates the request through LocalQueue, ClusterQueue, quota, priority, and ResourceFlavor policies. MultiKueue dispatches the admitted workload to an eligible bare-metal or managed cloud cluster. On a GPU worker, HAMi selects a compatible device and applies the requested GPU-memory and compute share.

The poster separates three decisions that are often conflated: when quota permits the notebook to run, which cluster receives it, and how accelerator capacity is allocated there. It also maps user-visible progress, failure states, timeout recovery, and cross-cluster cleanup.