GKE Cluster
Does ZopNight manage GKE Cluster?
A GKE cluster bills a per-cluster management fee plus the full Compute Engine price of every node VM. ZopNight discovers clusters through Cloud Asset Inventory, inventories 29 workload types inside each one, applies 43 GKE workload rules, and can scale every node pool to 0 on schedule, though the cluster fee continues at zero nodes.
Rules that fire on GKE Cluster
At a glance
| Field | Value |
|---|---|
| Scheduling notes | scales every node pool in the cluster to 0 nodes, saving original sizes and restoring them on resume |
Google Kubernetes Engine clusters run containerized workloads on managed node pools, billed a cluster management fee plus the full cost of every node VM. Dev and staging clusters running around the clock are among the biggest schedulable costs on GCP.
Two meters: a cluster fee plus every node VM
GKE splits its bill in two. The control plane charges a flat per-cluster management fee for every hour the cluster exists, regardless of what runs in it. The real money is the nodes: each node in each pool bills as an ordinary Compute Engine instance: vCPUs and memory per second, plus its boot disk at provisioned size. A cluster is therefore never cheaper than its node pools, and a ten-node dev cluster left running over a weekend pays for ten idle VMs plus the fee on top.
Cluster-level coverage in ZopNight
ZopDev discovers clusters via Cloud Asset Inventory, inventories 29 workload types inside each cluster, and applies 43 GKE workload rules. Beyond workloads, it computes CPU packing density (the ratio of pod CPU requests to node allocatable CPU) and flags clusters where less than 30 percent of node capacity is actually claimed, a reliable sign the pools are oversized relative to declared demand.
Scheduling a whole cluster to zero nodes
On a stop, ZopNight scales every node pool in the cluster to 0 nodes, saving the original sizes and restoring them on resume. Workloads suspend because there is nowhere to schedule them; the cluster object, its configuration, and its workload definitions all survive intact. The management fee keeps accruing at zero nodes; only deleting the cluster ends it. Node spend, which dominates, drops to nothing.
How GKE clusters overspend
Three patterns dominate. Non-production clusters running 168 hours a week for a working window a quarter that size. Pools sized for peak load with autoscaling minimums set so high they never scale in. And slack requests: teams that request far more CPU than pods use force the autoscaler to hold nodes that packing-density analysis shows are mostly empty.
Locating clusters in the console
Google Cloud console → Kubernetes Engine → Clusters lists every cluster with its node count and mode. Clicking through to a cluster shows its node pools and their current sizes. A scheduled-off cluster shows every pool at zero.