# Namespace

> Namespaces are the unit ZopNight switches off: at window close it scales Deployments, StatefulSets, and DaemonSets to 0, suspends CronJobs, and deletes-then-recreates HPAs and PDBs so no controller fights the scale-down, restoring everything at open. Discovery skips kube-system, kube-public, and kube-node-lease, and attaches a pod summary to each namespace.

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

---

A namespace partitions a cluster into logical environments: dev, staging, per-team spaces. It is also the one Kubernetes resource in this directory that is schedulable: when an environment goes quiet at night, the namespace is the handle ZopNight switches it off by.

## The unit an environment switches off at

Individual workloads are the wrong granularity for downtime, because a dev environment is dozens of objects that must stop and start together. Scheduling at the namespace boundary captures all of them in one decision, which is why the namespace record exists in the inventory even though the object itself has no cost: it is the parent that scheduling, eligibility, and attribution all key off.

## What stop actually does, object by object

At window close the schedule scales every Deployment, StatefulSet, and DaemonSet in the namespace to 0, suspends every CronJob, and deletes HPAs and PDBs after noting their specs. An HPA would scale everything back up, and a strict PDB would block the drain, so both are removed rather than argued with. At window open the workloads return to their prior counts, CronJobs unsuspend, and the deleted autoscalers and budgets are recreated as they were. Clusters running KEDA get the KEDA-aware variant so event-driven scaling is coordinated rather than fought.

## System namespaces stay out of scope

Discovery skips `kube-system`, `kube-public`, and `kube-node-lease` everywhere, and each provider adds its own exclusions, GKE's managed namespaces such as `gmp-system` among them. Nothing in those namespaces is ever inventoried as a workload or touched by a schedule; the same gates keep reserved namespaces out of scheduling eligibility.

## Pod summaries on the namespace record

Each discovered namespace carries its phase as status (`active` or `terminating`) plus labels and an attached pod summary counted at discovery time. That summary is the quick answer to the question that decides scheduling candidacy: is anything actually running in here, and how much of it?

```bash
kubectl get namespaces -o custom-columns=NAME:.metadata.name,STATUS:.status.phase,AGE:.metadata.creationTimestamp
```

A practical rule of thumb: environments whose namespaces show steady weekday pod counts and empty weekends are the first candidates worth scheduling, and the pod summary makes them visible in 1 pass.