Namespace vs Cluster Scheduling: Which to Stop at Night
Cluster-level scheduling parks everything; namespace-level scheduling parks only the workloads you choose. The right answer depends on who else lives on the cluster and how it is billed.
Kubernetes gives you two natural places to apply an off-hours schedule. Cluster-level scheduling takes capacity away from the whole cluster: its node pools scale down, or on AKS the cluster itself is stopped. Namespace-level scheduling leaves the cluster running and scales the workloads in selected namespaces to zero. Both reduce spend. They differ in blast radius, in what keeps billing, and in how the cluster behaves the next morning.
What each option switches off
| Cluster-level | Namespace-level | |
|---|---|---|
| Worker nodes | Removed or stopped | Only removed if the autoscaler or a node pool schedule drops them |
| Platform add-ons (ingress, operators, service mesh) | Stop with the cluster | Keep running |
| Other teams’ namespaces | Stop too | Unaffected |
| Control plane charge | Continues on EKS, GKE and AKS Standard; stops with an AKS cluster stop | Continues |
| Morning start | Nodes must be provisioned before Pods schedule | Pods schedule onto existing or autoscaled nodes |
What keeps billing after a cluster-level stop
The control plane is the part people forget. On EKS you pay per cluster per hour for standard Kubernetes version support (US$0.10), and scaling node groups to zero does not change that. On GKE a flat cluster management fee of US$0.10 per cluster per hour applies to every cluster regardless of mode or size, although the GKE free tier’s monthly credit covers one zonal or Autopilot cluster per billing account. So on those two providers a “stopped” cluster is a cluster with no nodes, not a cluster with no bill.
AKS is different because it has a native cluster stop. Stopping an AKS cluster deallocates the control plane and releases the capacity. Microsoft attaches conditions: the feature is for Virtual Machine Scale Set backed clusters, clusters using Node Autoprovisioning cannot be stopped, a stopped cluster’s state is preserved for up to 12 months, and while stopped you can only start or delete it. Microsoft also warns that in regions with capacity constraints you may be unable to start a stopped cluster, and recommends against stopping mission-critical workloads for that reason.
What keeps billing after a namespace-level stop
Scaling a namespace to zero removes Pods, so the saving depends on the billing model. Where Pods are billed directly, as on AWS Fargate or for GKE Autopilot general-purpose workloads (charged on Pod resource requests), the saving is immediate. On node-billed clusters the nodes keep billing until something removes them. Namespace scheduling therefore pairs with a cluster autoscaler that can scale emptied nodes down, or with a node pool dedicated to that environment and scheduled alongside it.
Choosing between them
Prefer cluster-level scheduling when the cluster serves one environment and one timetable, for example a dev cluster used only in working hours, and nothing on it has to answer at night. You recover the node cost in one move.
Prefer namespace-level scheduling when the cluster is shared: platform components other teams rely on, a qa namespace that sleeps and a perf namespace that runs overnight load tests. Stopping the cluster would take everyone down to save one team’s workloads.
Use both when a shared cluster has environment-specific node pools. Schedule the namespace so its Pods leave, and schedule or autoscale its node pool so the nodes follow.
How ZopNight handles each
ZopNight supports start/stop for EKS, GKE and AKS clusters, handling provider-specific operations such as EKS node pool scaling, and a separate namespace lifecycle for EKS, GKE and AKS namespaces that scales Deployments and StatefulSets to zero, suspends CronJobs, and restores replicas, HPAs and PDBs on start. System namespaces such as kube-system and default are never touched. The mechanics are covered in namespace-level scheduling, and node pool patterns in Kubernetes scheduling strategies. For cluster schedules on each cloud, see the GKE cluster and AKS cluster schedule pages.
Questions we get a lot.
If yours isn't here, email us and we'll answer directly.
Does scaling an EKS cluster's node groups to zero stop the EKS charge?
No. The per-cluster hourly charge for the EKS control plane continues for as long as the cluster exists. Scaling nodes to zero removes the node cost only.
Is stopping an AKS cluster risky?
Microsoft notes that in regions with capacity constraints you may not be able to start a stopped cluster, and recommends against stopping mission-critical workloads. Stopped cluster state is preserved for up to 12 months.