← Back to Labs

Kubernetes Scheduler Decision Lab

Follow one Pending Pod through queueing, filtering, scoring, preemption, and bind while switching between stateless, GPU, stateful, and high-priority workloads.

WorkloadSwap the incoming Pod and watch how one change in the manifest reshapes the node set
kube-schedulerPending in queuecheckout-api700m CPU · 768 MiBqueue + framework snapshotThe API replica is waiting in the active queue.podfra-a-01Frankfurt A · general pool4 vCPU · 8 GiB2.3 / 4 CPU · 4.2 / 8 GiBcluster state2 replicas already herefra-b-01Frankfurt B · general pool4 vCPU · 8 GiB1.6 / 4 CPU · 3.5 / 8 GiBcluster state1 replica hereams-a-gpuAmsterdam A · GPU pool8 vCPU · 32 GiB · 1 GPU2.0 / 8 CPU · 9 / 32 GiBcluster stategpu=true:NoScheduleams-b-dbAmsterdam B · NVMe stateful pool8 vCPU · 32 GiB · local PV2.5 / 8 CPU · 10 / 32 GiBcluster statestorage=nvme:NoSchedule
Hard rules
Linux nodes only. No GPU or storage tolerations.
Soft rules
Prefer even zone spread and warm images.
Feasible nodes
4
no node chosen yet
fra-a-01
General node with warm image cache.
2 replicas already here
fra-b-01
General node in the emptier zone.
1 replica here
ams-a-gpu
GPU pool is available but currently unnecessary.
gpu=true:NoSchedule
ams-b-db
Stateful pool is healthy but reserved for storage-heavy work.
storage=nvme:NoSchedule
Step 1 / 6Queued

The Pod enters the scheduler queue with its requests and placement rules. Nothing has been chosen yet.

Existing replicas are already split 2 in Frankfurt A and 1 in Frankfurt B. Spread only matters after the scheduler proves at least one node can fit the new Pod.

Arrow keys to navigate · R to reset

Tap dots to jump to any step

Read the full article →Take the quiz →