Stopping a Kubernetes Cluster at Night on EKS, GKE and AKS

“Stop the cluster overnight” means three different things depending on the cloud. Azure Kubernetes Service has a real cluster stop that halts the control plane and the nodes. Amazon EKS and Google Kubernetes Engine have no equivalent: the control plane runs as long as the cluster exists, and the only thing you can switch off is worker capacity. Pick the procedure for your provider below, then read the section on what each one leaves behind.

For the node-level mechanics that apply to all three (draining, PodDisruptionBudgets, system pools), see draining and resizing node pools.

AKS: stop the entire cluster

az aks stop stops the control plane and every agent node. All Kubernetes objects are kept except standalone Pods (Pods not owned by a controller), and the state is restored on start.

az aks stop  --name dev-aks --resource-group rg-dev
az aks show  --name dev-aks --resource-group rg-dev --query powerState.code -o tsv
# Stopped

# Wait 15-30 minutes after a stop before starting again: Microsoft warns that
# starting too soon can disrupt the shutdown.
az aks start --name dev-aks --resource-group rg-dev
az aks show  --name dev-aks --resource-group rg-dev --query powerState.code -o tsv
# Running

Permissions: the caller needs Microsoft.ContainerService/managedClusters/stop/action and .../start/action on the cluster.

Limits Microsoft documents for this feature:

• Only clusters backed by Virtual Machine Scale Sets can be stopped, and clusters using Node Autoprovisioning cannot.
• A stopped cluster accepts only start or delete. Scaling and upgrades wait until it is running.
• State is kept for up to 12 months; after that it cannot be recovered.
• Stopping releases the capacity. In a capacity-constrained region the start can fail, which is why Microsoft advises against stopping mission-critical clusters.
• Do not start the cluster while provisioningState still reads Stopping.

If a full stop is too blunt, scale only the user node pools to zero and leave the system pool running (system pools need at least two nodes).

EKS: scale managed node groups to zero

There is no EKS cluster stop. Set each managed node group’s minimum and desired size to zero; maxSize must stay at 1 or more.

aws eks describe-nodegroup --cluster-name dev-eks --nodegroup-name apps \
  --query 'nodegroup.scalingConfig'
# note minSize / maxSize / desiredSize for the morning

aws eks update-nodegroup-config --cluster-name dev-eks --nodegroup-name apps \
  --scaling-config minSize=0,maxSize=3,desiredSize=0

IAM actions: eks:DescribeNodegroup and eks:UpdateNodegroupConfig. The eksctl equivalent is eksctl scale nodegroup --cluster=dev-eks --name=apps --nodes=0 --nodes-min=0.

Two EKS specifics worth knowing before you automate this. First, reducing the desired count does not respect PodDisruptionBudgets: EKS tries to evict Pods and terminates the node after 15 minutes regardless. Second, if the Kubernetes Cluster Autoscaler runs in the cluster, AWS warns against changing desiredSize directly, because the autoscaler may immediately scale the group back.

In the morning run the same command with the recorded values, then confirm with aws eks describe-nodegroup that status is back to ACTIVE and the nodes are Ready in kubectl get nodes.

GKE: resize node pools to zero

GKE clusters cannot be stopped either. On a Standard cluster, disable autoscaling on a pool and resize it to zero; keep at least one pool for system Pods, because the autoscaler never takes a Standard cluster to zero nodes. The full command sequence is in scaling GKE node pools to zero. Autopilot has no user node pools to resize; scale the workloads instead.

What each option leaves billing

On AKS, cluster management is free on the Free tier; the Standard and Premium tiers carry a charge for it.

Scheduling it with ZopNight

ZopNight lists EKS, GKE and AKS among the resource types it can start and stop, handling the provider-specific operation for each (for EKS, node pool scaling), and runs the change from a schedule of cron expressions in an IANA timezone. Scheduled execution needs the cloud account connected with read + write; read-only accounts get discovery and recommendations only. Cluster start and stop run synchronously, without a background watcher, so check the result in the state history. See the AKS cluster schedule page and the EKS node group schedule page for resource-level notes.