# Scheduling 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.

Source: https://zop.dev/integrations/kubernetes/namespace/schedule
Updated: 2026-08-19

---

## 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.