Scheduling AKS Agent Pool
Can ZopNight schedule AKS Agent Pool?
Agent pool schedules scale a pool to 0 nodes and restore the saved count at start, but only user pools qualify: AKS requires the system pool to keep at least 1 node for cluster plumbing. Evicted pods wait as Pending or migrate to surviving pools, and the cluster autoscaler can quietly reverse the scale-down.
How the stop works
| Field | Value |
|---|---|
| Behaviour | scaled to 0 nodes on stop, with the prior node count saved and restored on start. |
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
System pools cannot reach zero
AKS draws a line between pool types. System node pools host CoreDNS and the other components the cluster cannot live without, and AKS enforces a minimum of 1 node there. User pools carry no such floor and scale to 0 cleanly. A schedule therefore targets user pools; anyone wanting the whole cluster dark, system pool included, is looking for the cluster-level stop instead, which is a different mechanism with different trade-offs.
Prior count saved, then restored
At stop the pool’s current node count is recorded, and the start run scales back to exactly that number. Changes made in between, such as an engineer manually bumping the pool at 11pm, are overwritten by the restore. The recorded value, not the latest one, wins the morning.
Where the workloads end up overnight
Draining a pool to zero evicts its pods. Those pinned to the pool by labels, taints or GPU requests sit Pending until nodes return. Unpinned pods can reschedule onto other pools that have room. They stay up, and their compute cost transfers to those pools rather than disappearing. When measuring the saving, look at cluster-wide node spend, not just the scheduled pool’s line.
Mind the autoscaler
A pool managed by the cluster autoscaler will be scaled back up the moment Pending pods demand it; the autoscaler neither knows nor cares about the calendar. Scheduled pools should either sit outside autoscaler scope or host workloads that genuinely produce no Pending pressure at night.
Zero nodes is not a zero bill
The pool’s VMs stop billing, but the cluster around it does not: a paid-tier control plane, load balancers, public IPs and any persistent disks all charge on. Disks detached from scaled-away nodes persist by design, which is what makes the morning restore stateful, and they bill per GB regardless of node count.