Scheduling Namespace
Can ZopNight schedule Namespace?
Namespace schedules apply a different treatment per controller: Deployments, StatefulSets and DaemonSets scale to 0, CronJobs are suspended, and HPAs and PDBs are deleted then recreated on resume. A live HPA would scale workloads straight back up, and a PDB would block the drain.
How the stop works
| Field | Value |
|---|---|
| Behaviour | scales all Deployments, StatefulSets, and DaemonSets to 0, suspends CronJobs, and deletes-then-recreates HPAs and PDBs so nothing fights the scale-down; fully restored on schedule 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
Why this schedule is a choreography
A namespace is a bag of controllers that each resist shutdown in their own way, so the stop is several coordinated moves rather than one. Deployments, StatefulSets and DaemonSets scale to 0 replicas. CronJobs flip to suspended so no new runs launch. And the objects that would fight the scale-down are deleted outright and recreated faithfully at resume: HorizontalPodAutoscalers, which would immediately scale workloads back up, and PodDisruptionBudgets, which would block the evictions. Editing them in place is not enough; their entire job is to oppose exactly what the schedule is doing.
What the sweep does not manage
Bare pods with no controller keep running, since nothing owns them and nothing scales them. Jobs already mid-run continue to completion. Operators and CRDs that reconcile their own replica counts can resurrect workloads minutes after the scale-down; a namespace running such an operator needs it included in the schedule’s scope or excluded from the namespace. PersistentVolumeClaims survive untouched, holding both the state and the storage bill.
Zero pods is not automatically zero dollars
Everything here happens inside the cluster, and clouds bill for nodes, not pods. The scaled- down namespace saves real money only when the freed capacity lets nodes disappear, whether through a cluster autoscaler consolidating and removing emptied nodes or a companion schedule on the node pools. On a fixed-size cluster the schedule frees headroom, which has value, but the invoice does not change.
Suspended CronJobs do not backfill
A CronJob suspended at 19:00 with 6 scheduled runs overnight executes none of them at resume. Suspension skips occurrences rather than queueing them. Jobs whose runs matter individually need their schedules moved inside the window, not merely suspended through it.
Resume rebuilds the guardrails
At start, replicas return to their recorded counts, CronJobs unsuspend, and the deleted HPAs and PDBs are recreated from their saved definitions. The namespace ends the cycle with its autoscaling and disruption protection intact, not permanently stripped.