Scheduling GKE Cluster
Can ZopNight schedule GKE Cluster?
GKE cluster schedules scale every node pool to 0, saving each pool's size and restoring it at start. The control plane keeps running throughout, so kubectl and GitOps work all night against a cluster with no nodes. The management fee of $0.10 per cluster-hour continues regardless.
How the stop works
| Field | Value |
|---|---|
| Behaviour | scales every node pool in the cluster to 0 nodes, saving original sizes and restoring them 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
Nodes leave, the control plane stays
Scaling all node pools to 0 empties the cluster of compute while leaving the API server reachable. Every workload sits Pending, but kubectl responds, manifests apply, and GitOps controllers reconcile all night: the reconciled state simply has nowhere to run until nodes return. Overnight CI that only applies manifests keeps passing; anything that waits for a rollout to become ready will hang until morning.
The fee that ignores the schedule
GKE charges a flat management fee of $0.10 per cluster per hour, roughly $73 a month, no matter how many nodes exist, with the free tier covering one zonal or Autopilot cluster per account. A scheduled-to-zero cluster keeps paying it. For a fleet of small dev clusters the fee becomes the dominant residual, which is a quiet argument for fewer, shared dev clusters rather than one per team.
Autopilot clusters sit outside this mechanism entirely. They bill per pod rather than per node, and have no user-managed pools to scale.
Per-pool memory, per-pool restore
Each pool’s node count is recorded at stop and reinstated at start, pool by pool. A cluster with a system pool of 3 and a GPU pool of 2 comes back as exactly that. Interim manual edits made while the pools sit at zero are overwritten by the recorded sizes.
System workloads go Pending too
Emptying every pool evicts cluster add-ons along with application pods. They recover unaided when nodes return, but the morning has an ordering: nodes register, system pods land first, then the application backlog places. Allow 5-10 minutes from the start cron before health checks judge the result.
Automation that refills pools
Node auto-provisioning and pool-level autoscalers respond to Pending pods, and a scaled-to-zero cluster is nothing but Pending pods. Left enabled overnight, they will faithfully undo the schedule. Scheduled clusters need those features scoped, disabled at night, or hosting only workloads that scale to zero themselves.