Identify idle GKE clusters

You can identify idle Google Kubernetes Engine (GKE) Standard clusters using insights and recommendations. After you verify that the identified idle clusters are unused, you can delete them to save costs. If possible, the recommendation includes projected monthly savings for deleting a cluster. For more information, see Understand cost estimation for idle clusters.

GKE provides insights and recommendations for cost optimization scenarios such as underprovisioned clusters, overprovisioned clusters, and idle clusters, with corresponding recommendations to scale up, scale down, or delete the clusters. This page explains how to identify idle clusters. See also, Identify underprovisioned and overprovisioned GKE clusters.

GKE doesn't provide insights for Autopilot clusters, which incur minimal operational costs as you only pay for the resources that your workloads request. For more information, see Autopilot Pricing.

GKE monitors your clusters and delivers guidance to optimize your usage through Active Assist, a service that provides recommenders that generate insights and recommendations for using resources on Google Cloud.

For more information about how to manage insights and recommendations, see Optimize your usage of GKE with insights and recommendations.

Identify idle clusters

To identify idle clusters, view insights and recommendations using the Google Cloud console, the Google Cloud CLI, or the Recommender API. Use the insight subtypes shown in the table in the following section and the CLUSTER_IDLE recommendation subtype. In the console, these insights appear in the Cost Optimization tab on the Clusters page.

After you identify idle clusters, see the considerations when deleting idle clusters.

How GKE identifies idle clusters

GKE uses utilization signals to determine whether you receive an insight and recommendation.

The following table describes the signals that GKE uses and the threshold for each signal. Each signal triggers an independent insight. If a cluster has multiple insights, GKE displays a single recommendation.

Insight subtype Signal Observation period Details
CLUSTER_IDLE_NO_RUNNING_PODS No running customer Pods Last 30 days There are zero Pods in the Running state outside of the kube-system and gmp-system namespace in the cluster metrics events logs for the cluster during the last 30 days.
CLUSTER_IDLE_NO_NODES No nodes or node pools Last 30 days There are zero nodes or zero node pools in the cluster metrics events logs for the cluster during the last 30 days.
CLUSTER_IDLE_LOW_CPU_UTILIZATION Low CPU utilization and no new Pods Last 30 days A GKE cluster is idle with low CPU utilization when both of the following are true:
  • CPU utilization consistently averages under 7% during every hour, over the last 30 days.
  • Active Pod count remains unchanged over the last 30 days.

GKE doesn't send recommendations for clusters that were created less than 30 days ago.

Understand cost estimation for idle clusters

If possible, GKE includes with the recommendation an estimated monthly cost of the idle cluster, projecting how much money you'd save each month if you deleted the cluster. This estimate is derived from the cluster costs over the past 30 days.

Any estimated savings are projections based on previous spending, and are not a guarantee of future cost or savings.

To see these estimates, ensure that you have the required billing.accounts.getSpendingInformation permission to get spending information. For details, see Cloud Billing access.

To get more information about the cost of all of your GKE clusters, including a more granular breakdown based on namespaces and workloads, see Get key spending insights for your GKE resource allocation and cluster costs.

For more information about the costs of running a GKE cluster, see GKE pricing.

Considerations when deleting idle clusters

Before you delete a cluster that GKE determines is idle, consider the following possibilities:

  • Does anyone use the cluster? For example, a cluster might be intentionally idle if its purpose is to maintain failover capacity.
  • Should the cluster be scaled down instead of deleted? For example, a cluster running a useful workload might have low utilization and be identified as idle because more resources were provisioned than necessary.

Implement the recommendation to delete idle clusters

If you've received an insight and recommendation that you have an idle cluster that can be deleted and have ruled out the considerations for keeping the cluster running, follow the instructions in the recommendation and delete the cluster.

What's next