Scheduling GKE Node Pool
Can ZopNight schedule GKE Node Pool?
A node pool schedule scales just that pool to 0 and reinstates the recorded size on resume. Whether money is actually saved depends on the pods: workloads pinned by selectors go Pending, but unpinned pods reschedule onto the other pools, where they keep running and billing on different nodes.
How the stop works
| Field | Value |
|---|---|
| Behaviour | scales the node pool to 0 nodes, recording the previous size for restoration on resume |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
Zero for one pool, business as usual elsewhere
The schedule targets a single pool (commonly the expensive one, GPU or high-memory), scales it to 0 nodes and records the previous size for the resume. The rest of the cluster keeps its nodes, its add-ons and its workloads, which is what makes single-pool scheduling attractive: the blast radius is one team’s hardware, not the shared cluster.
Pods do not always go quiet, some just move
Eviction gives every displaced pod a choice made by the scheduler. Pods bound to the pool by node selectors, taints, tolerations or GPU resource requests have nowhere to go and wait as Pending, costing nothing. Pods that merely happened to be on the pool are rescheduled onto whatever else has room. They keep running, and their consumption shifts onto the surviving pools, potentially triggering scale-up there. The saving is real only for the pinned workloads; measure cluster-wide node spend before and after, not the scheduled pool alone.
The autoscaler will refill what pods demand
A pool under cluster-autoscaler management scales back up when Pending pods request its resources. If anything overnight creates pods pinned to the scheduled pool, say a CronJob requesting a GPU at 1am, the autoscaler obliges and the pool quietly runs all night. Either exclude the pool from autoscaling during the window or move those jobs inside business hours.
Resume restores the recorded size
The pool returns to the count captured at stop time, not to whatever someone set in between. Nodes then boot, join and pass readiness before the Pending backlog schedules. On GPU pools with driver installation, that is minutes, so lead the first training job accordingly.
The natural fit
GPU pools used interactively by researchers are the canonical case. Pinned workloads, diurnal usage and expensive nodes are every property this schedule wants, with 12-14 idle hours a night to harvest.