Scheduling Azure Kubernetes Service Cluster
Can ZopNight schedule Azure Kubernetes Service Cluster?
AKS cluster schedules use the native Stop operation, which deallocates every agent node and shuts down the control plane while preserving all cluster state. Overnight, kubectl, GitOps and CI deployments all fail because the API server is off; start takes 5-10 minutes and node capacity is requested fresh.
How the stop works
| Field | Value |
|---|---|
| Behaviour | uses the native AKS cluster Stop/Start operation, which deallocates all agent nodes while preserving cluster state. |
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
The control plane goes down too
AKS cluster Stop is more total than scaling pools away: agent nodes are deallocated and the control plane itself shuts down. The cluster’s state (workload definitions, config, secrets) is preserved and everything returns on Start. In exchange, the cluster is genuinely unreachable overnight. That completeness is the feature and the constraint at once.
Everything that talks to the API server breaks
With the API server off, kubectl times out, Argo and Flux cannot reconcile, CI pipelines that deploy at night fail, and monitoring that scrapes the API reports the cluster missing. Overnight deploy jobs need rescheduling into business hours or teaching to check the window first. Treat the alert noise from the first scheduled night as a checklist of integrations nobody documented.
Deallocated nodes, preserved shape
Agent nodes are deallocated rather than deleted, so the cluster’s node topology comes back as it was. Start requests compute capacity fresh, and for constrained sizes, GPU SKUs above all, that request can fail at 7am. Common general-purpose sizes rarely hit this; a cluster full of scarce SKUs should weigh the risk before adopting a nightly stop.
Minutes to come back, in sequence
Start brings up the control plane, reallocates nodes, and waits for them to register before pods reschedule. Plan for 5-10 minutes on a small cluster, more with many pools. Anything verifying the cluster at 8:00 sharp should instead verify at 8:15 with the start cron at 8:00 or earlier.
Avoid rapid stop-start cycling while you are at it. Let each operation finish before issuing the next, or the cluster can wedge in a transitional state that needs support to unpick.
What the stop does not stop
Node compute and the per-cluster uptime charge go quiet, but managed disks bill on, as do public IPs, and load balancers. External dependencies such as container registries, key vaults and the databases the cluster talks to have their own meters and their own schedules if they need them.