/

Console

• English
• Deutsch
• Español
• Español – América Latina
• Français
• Indonesia
• Italiano
• Português
• Português – Brasil
• עברית
• 中文 – 简体
• 中文 – 繁體
• 日本語
• 한국어

Sign in

• Google Kubernetes Engine (GKE)

Start free

Collect and view kube state metrics

This page describes how to configure a Google Kubernetes Engine (GKE) cluster to send a curated set of kube state, including metrics for Pods and Deployments, Cloud Monitoring using Google Cloud Managed Service for Prometheus. This page also describes how these metrics are formatted when they are written to Monitoring, and how to query metrics.

Before you begin

Before you start, make sure that you have performed the following tasks:

• Enable the Google Kubernetes Engine API.
Enable Google Kubernetes Engine API
• If you want to use the Google Cloud CLI for this task, install and then initialize the gcloud CLI. If you previously installed the gcloud CLI, get the latest version by running the gcloud components update command. Earlier gcloud CLI versions might not support running the commands in this document.

Requirements

To collect kube state metrics, your GKE cluster must meet the following requirements:

• The cluster must be running the following versions based on the metric that you want to enable:
  • To enable JobSet metrics package, your cluster must run 1.32.1-gke.1357001 or later. Starting with version 1.32.1-gke.1357001, the JobSet metrics package is enabled by default on newly created GKE Standard and Autopilot clusters.
  • kube_jobset_restarts metric is available in 1.32 clusters starting from 1.32.4-gke.1767000 and in 1.33 clusters starting from 1.33.0-gke.1868000.
  • To enable any other metric packages described in this page, your cluster must run GKE 1.27.2-gke.1200 or later. Starting with version 1.29.2-gke.2000 for GKE Standard clusters and version 1.27.4-gke.900 for GKE Autopilot clusters, the Kube state metrics package is enabled by default.
• The cluster must have system metrics enabled.
• The cluster must have Google Cloud Managed Service for Prometheus managed collection enabled. Google Cloud Managed Service for Prometheus managed collection is enabled by default for new clusters.

Configure the collection of kube state metrics

You can enable kube state metrics using the Google Cloud console, the gcloud CLI, or Terraform:

gcloud container clusters update CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --enable-managed-prometheus \
    --monitoring=SYSTEM,DAEMONSET,DEPLOYMENT,HPA,POD,STATEFULSET,STORAGE

Quota

Kube state metrics consume the Time series ingestion requests per minute quota of the Cloud Monitoring API. Before enabling kube state metrics, check your recent peak usage of that quota. If you have many clusters in the same project or are already approaching that quota limit, you can request a quota limit increase before enabling either observability package.

Pricing

Kube state metrics use Google Cloud Managed Service for Prometheus to load metrics into Cloud Monitoring. Cloud Monitoring charges for the ingestion of these metrics are based on the number of samples ingested.

For more information, see Cloud Monitoring pricing.

Metric format

All Kubernetes kube state metrics written to Cloud Monitoring use the resource type prometheus_target. Each metric name is prefixed with prometheus.googleapis.com/ and has a suffix indicating the Prometheus metric type, such as /gauge, /histogram, or /counter. Otherwise, each metric name is identical to the metric name exposed by open source Kubernetes.

Exporting from Cloud Monitoring

The kube state metrics can be exported from Cloud Monitoring by using the Cloud Monitoring API. Because all kube state metrics are ingested by using Google Cloud Managed Service for Prometheus, kube state metrics can be queried by using Prometheus Query Language (PromQL). They can also be queried by using by using Monitoring Query Language (MQL).

Querying metrics

When you query kube state metrics, the name you use depends on whether you are using PromQL or Cloud Monitoring-based features like MQL or the Metrics Explorer menu-driven interface.

The following tables of kube state metrics show two versions of each metric name:

• PromQL metric name: When using PromQL in Cloud Monitoring pages of the Google Cloud console or in PromQL fields of the Cloud Monitoring API, use the PromQL metric name.
• Cloud Monitoring metric name When using other Cloud Monitoring features, use the Cloud Monitoring metric name in the tables below. This name must be prefixed with prometheus.googleapis.com/, which has been omitted from the entries in the table.

Storage metrics

The Cloud Monitoring metric names in this table must be prefixed with prometheus.googleapis.com/. That prefix has been omitted from the entries in the table.

For more information, see PersistentVolume Metrics and PersistentVolumeClaim Metrics.

Pod metrics

A Pod is a group of one or more containers with a specification for how to run the containers, which share storage and network resources.

Table of Pod metrics

The Pod metrics let you monitor and alert on the behavior of your Pods. The following table shows the metrics available in the kube state metrics package.

The Cloud Monitoring metric names in this table must be prefixed with prometheus.googleapis.com/. That prefix has been omitted from the entries in the table.

For more information, see Pod Metrics.

Sample queries for Pod metrics

To determine if you have unschedulable Pods, use the following PromQL expression:

sum(kube_pod_status_unschedulable{cluster="CLUSTER", namespace="NAMESPACE"})

To alert on a number of unschedulable pods in a namespace, you can use the following PromQL expression:

sum(kube_pod_status_unschedulable{cluster="CLUSTER", namespace="NAMESPACE"}) > LIMIT

You can use the kube_pod_container_status_waiting_reason metric to create an alert for a container stuck in a specific waiting state by using a PromQL expression like the following:

max_over_time(kube_pod_container_status_waiting_reason{reason="REASON", cluster="CLUSTER", namespace="NAMESPACE"}[5m]) >= 1

The value of REASON specifies the container's waiting state, for example:

• CrashLoopBackOff
• ImagePullBackOff
• ContainerCreating

To create an alert for a container stuck in any of the waiting states, use the following PromQL expression:

max_over_time(kube_pod_container_status_waiting_reason{cluster="CLUSTER", namespace="NAMESPACE"}[5m]) >= 1

To determine how many containers are failing readiness checks, use the following PromQL expression

sum(kube_pod_container_status_ready) by (pod, container) == 0

Some of the query and alert expressions in this section were adapted from the kubernetes-apps.yaml file in the Prometheus community Kubernetes Helm Charts repository on GitHub.

Interactive playbooks

Kube state metrics are also used in the GKE interactive playbooks for troubleshooting unschedulable or crashlooping Pods. For more information about these failure modes, see the following troubleshooting documents:

• Crashlooping Pods
• Unschedulable Pods

Without the kube state metrics package enabled, the primary way to detect pod-scheduling issues is to query "Failed Scheduling" log events. After you enable the kube state metrics package, you can use the kube_pod_status_unschedulable metric, which serves the same purpose but is easier to aggregate and chart. By using the metric, you can see how many Pods are unschedulable and when the problem started.

Similarly, the GKE system metric kubernetes.io/container/restart_count can help you detect crashlooping Pods. The kube_pod_container_status_waiting_reason metric also enumerates crashlooping Pods, and it also lets you determine if Pods are stuck in waiting states other than CrashLookBackOff, like ImagePullBackOff and ContainerCreating.

To explore the interactive playbooks, do the following:

1. In the Google Cloud console, go to the dashboard Dashboards page:

   Go to Dashboards

   If you use the search bar to find this page, then select the result whose subheading is Monitoring.

2. Filter the dashboard list by clicking the G​C​P category.
3. Click the name of a "GKE Interactive Playbook" dashboard in the list.

Deployment metrics

A Deployment is a controller that updates the state of resources like Pods, to manage events like rollouts and turndowns.

Table of Deployment metrics

The Deployment metrics let you monitor and alert on the behavior of the controller. The following table shows the metrics available in the kube state metrics package:

The Cloud Monitoring metric names in this table must be prefixed with prometheus.googleapis.com/. That prefix has been omitted from the entries in the table.

For more information, see Deployment Metrics.

Sample queries for Deployment metrics

You can create charts and alerting policies for individual Deployments by filtering Deployment metrics by cluster, namespace, and the name of the Deployment.

For example, to compare the number of available replicas to the expected number of replicas in a single Deployment, you can use the following PromQL queries to plot both metrics on a single chart:

kube_deployment_spec_replicas{cluster="CLUSTER", namespace="NAMESPACE", deployment=DEPLOYMENT"}

kube_deployment_status_replicas_available{cluster="CLUSTER", namespace="NAMESPACE", deployment=DEPLOYMENT"}

To alert on a failed or stalled Deployment, you can use the following PromQL expression:

(
  kube_deployment_spec_replicas{cluster="CLUSTER", namespace="NAMESPACE", deployment="DEPLOYMENT"}
    >
  kube_deployment_status_replicas_available{cluster="CLUSTER", namespace="NAMESPACE", deployment="DEPLOYMENT"}
) and (
  changes(kube_deployment_status_replicas_updated{cluster="CLUSTER", namespace="NAMESPACE", deployment="DEPLOYMENT"}[10m])
    ==
  0
)

Some of the query and alert expressions in this section were adapted from the kubernetes-apps.yaml file in the Prometheus community Kubernetes Helm Charts repository on GitHub.

StatefulSet metrics

A StatefulSet is a controller that manages the deployment and scaling of a set of Pods for stateful applications. This controller manages the the ordering and uniqueness of Pods.

Table of StatefulSet metrics

The StatefulSet metrics let you monitor and alert on the behavior of the controller. The following table shows the metrics available in the kube state metrics package:

The Cloud Monitoring metric names in this table must be prefixed with prometheus.googleapis.com/. That prefix has been omitted from the entries in the table.

For more information, see StatefulSet Metrics.

Sample queries for StatefulSet metrics

You can create charts and alerting policies for individual StatefulSets by filtering statefulset metrics by cluster, namespace, and the name of the StatefulSet.

For example, to compare the number of available replicas to the expected number of replicas in a single StatefulSet, you can use the following PromQL queries to plot both metrics on a single chart:

kube_statefulset_replicas{cluster="CLUSTER", namespace="NAMESPACE", statefulset="STATEFULSET"}

kube_statefulset_status_replicas_ready{cluster="CLUSTER", namespace="NAMESPACE", statefulset="STATEFULSET"}

To alert on a failed or stalled StatefulSet rollout, you can use the following PromQL expression:

(
  kube_statefulset_replicas{cluster="CLUSTER", namespace="NAMESPACE", statefulset="STATEFULSET"}
    >
  kube_statefulset_status_replicas_ready{cluster="CLUSTER", namespace="NAMESPACE", statefulset="STATEFULSET"}
) and (
  changes(kube_statefulset_status_replicas_updated{cluster="CLUSTER", namespace="NAMESPACE", statefulset="STATEFULSET"}[10m])
    ==
  0
)

Some of the query and alert expressions in this section were adapted from the kubernetes-apps.yaml file in the Prometheus community Kubernetes Helm Charts repository on GitHub.

DaemonSet metrics

A DaemonSet is a controller that helps ensure that some set of Nodes runs a copy of a Pod. For example, as Nodes are added to a cluster, the DaemonSet adds Pods to the Nodes. This controller helps ensure that certain processes run on every node.

Table of DaemonSet metrics

The DaemonSet metrics let you monitor and alert on the behavior of the controller. The following table shows the metrics available in the kube state metrics package:

The Cloud Monitoring metric names in this table must be prefixed with prometheus.googleapis.com/. That prefix has been omitted from the entries in the table.

For more information, see DaemonSet Metrics.

Sample queries for DaemonSet metrics

You can create charts and alerting policies for individual DaemonSets by filtering daemonset metrics by cluster, namespace, and the name of the DaemonSet.

For example, to compare the number of available replicas to the expected number of replicas in a single DaemonSet, you can use the following PromQL queries to plot both metrics on a single chart:

kube_daemonset_status_updated_number_scheduled{cluster="CLUSTER", namespace="NAMESPACE", daemonsetset=DAEMONSET"}

kube_daemonset_status_desired_number_scheduled{cluster="CLUSTER", namespace="NAMESPACE", daemonset=DAEMONSET"}

To alert on a failed or stalled DaemonSet rollout, you can use the following PromQL expression:

(
  (
    kube_daemonset_status_number_misscheduled{cluster="CLUSTER", namespace="NAMESPACE", daemonset="DAEMONSET"}
      !=
    0
  ) or (
    kube_daemonset_status_updated_number_scheduled{cluster="CLUSTER", namespace="NAMESPACE", daemonset="DAEMONSET"}
      !=
    kube_daemonset_status_desired_number_scheduled{cluster="CLUSTER", namespace="NAMESPACE", daemonset="DAEMONSET"}
  )
) and (
  changes(kube_daemonset_status_updated_number_scheduled{cluster="CLUSTER", namespace="NAMESPACE", daemonset="DAEMONSET"}[5m])
    ==
  0
)

Some of the query and alert expressions in this section were adapted from the kubernetes-apps.yaml file in the Prometheus community Kubernetes Helm Charts repository on GitHub.

HorizontalPodAutoscaler metrics

A HorizontalPodAutoscaler (HPA) is a controller that periodically changes the number of pods in a workload, such as a Deployment or StatefulSet, in response to some metric like CPU or memory utilization. Changing the number of pods available to a workload keeps the workload responsive but efficient.

For more information about HPAs, see Viewing details about a Horizontal Pod Autoscaler.

Table of HPA metrics

The HorizontalPodAutoscaler metrics let you monitor and alert on the behavior of the controller. The following table shows the metrics available in the kube state metrics package:

The Cloud Monitoring metric names in this table must be prefixed with prometheus.googleapis.com/. That prefix has been omitted from the entries in the table.

For more information, see Horizontal Pod Autoscaler Metrics.

Sample queries for HPA metrics

For example, to determine if the HPA is approaching the maximum number of replicas, you can plot the following ratio:

kube_horizontalpodautoscaler_status_current_replicas{cluster="CLUSTER", namespace="NAMESPACE", horizontalpodautoscaler="HPA"} /
kube_horizontalpodautoscaler_spec_max_replicas{cluster="CLUSTER", namespace="NAMESPACE", horizontalpodautoscaler="HPA"}

When the HPA is running with the maximum number of replicas, you might want to increase the spec for maximum number of pods. You can use the following PromQL expression to create an alert to notify you of this case:

kube_horizontalpodautoscaler_status_current_replicas{cluster="CLUSTER", namespace="NAMESPACE", horizontalpodautoscaler="HPA"}
  ==
kube_horizontalpodautoscaler_spec_max_replicas{cluster="CLUSTER", namespace="NAMESPACE", horizontalpodautoscaler="HPA"}

You can also compare the values of the kube_horizontalpodautoscaler_status_current_replicas and the kube_horizontalpodautoscaler_status_desired_replicas metrics to determine if there is a difference between the current and needed number of replicas. A difference might may indicate a resource constraint in the cluster. The following PromQL expression looks for differences between the current number of replicas and the needed, minimum, and maximum numbers of replicas, as well as changes in the current number of replicas:

(kube_horizontalpodautoscaler_status_desired_replicas{job="kube-state-metrics", namespace=~"NAMESPACE"}
  !=
kube_horizontalpodautoscaler_status_current_replicas{job="kube-state-metrics", namespace=~"NAMESPACE"})
  and
(kube_horizontalpodautoscaler_status_current_replicas{job="kube-state-metrics", namespace=~"NAMESPACE"}
  >
kube_horizontalpodautoscaler_spec_min_replicas{job="kube-state-metrics", namespace=~"NAMESPACE"})
  and
(kube_horizontalpodautoscaler_status_current_replicas{job="kube-state-metrics", namespace=~"NAMESPACE"}
  <
kube_horizontalpodautoscaler_spec_max_replicas{job="kube-state-metrics", namespace=~"NAMESPACE"})
  and
changes(kube_horizontalpodautoscaler_status_current_replicas{job="kube-state-metrics", namespace=~"NAMESPACE"}[15m]) == 0

The condition and status labels on the kube_horizontalpodautoscaler_status_condition metric can also help you detect when HPAs run into various failure modes. For example:

• The condition ScalingLimited and status of true indicates that the HPA is bound by either its minimum or maximum replica count:

  kube_horizontalpodautoscaler_status_condition{status="true", condition="ScalingLimited"} == 1

• The condition AbleToScale and a status of false indicates that the HPA is encountering issues fetching or updating scales:

  kube_horizontalpodautoscaler_status_condition{status="false", condition="AbleToScale"} == 1

• The condition ScalingActive and a status of false indicates that the HPA is disabled or is unable to calculate a new scale:

  kube_horizontalpodautoscaler_status_condition{status="false", condition="ScalingActive"} == 1

Some of the query and alert expressions in this section were adapted from the kubernetes-apps.yaml file in the Prometheus community Kubernetes Helm Charts repository on GitHub.

JobSet metrics

A Jobset is a workload API that lets you manage a group of Kubernetes Jobs as a unit. The most common use case for a JobSet is distributed training, but you can also use it to run batch workloads.

For more information about JobSets, see JobSet Documentation.

Table of JobSet metrics

The JobSet metrics let you monitor and alert on the behavior of your JobSets. The following table shows the metrics that are available in the kube state metrics package:

The Cloud Monitoring metric names in this table must be prefixed with prometheus.googleapis.com/. That prefix has been omitted from the entries in the table.

Sample queries for JobSet metrics

You can create charts and alerting policies for individual JobSets by filtering JobSet metrics by cluster, namespace, and the name of the JobSet.

For example, to compare the number of replicas in a READY state to the expected number of replicas in a single JobSet, plot both metrics on a single chart by using the following PromQL queries:

kube_jobset_specified_replicas{cluster="CLUSTER", namespace="NAMESPACE", jobset_name="JOBSET_NAME"}

kube_jobset_ready_replicas{cluster="CLUSTER", namespace="NAMESPACE", jobset_name="JOBSET_NAME"}

To alert on a failed or unavailable JobSet rollout, you can use the following PromQL expression:

kube_jobset_specified_replicas{cluster="CLUSTER", namespace="NAMESPACE", jobset_name="JOBSET_NAME"}
  >
kube_jobset_ready_replicas{cluster="CLUSTER", namespace="NAMESPACE", jobset_name="JOBSET_NAME"}

The condition label on the kube_jobset_status_condition metric can also help you detect when JobSets run into various failure modes, for example:

• The Failed condition indicates that the JobSet failed its execution:

  kube_jobset_status_condition{jobset_name="JOBSET_NAME, condition="Failed"} == 1

• The Suspended condition indicates that the JobSet is suspended:

  kube_jobset_status_condition{jobset_name="JOBSET_NAME, condition="Suspended"} == 1

Some of the query and alert expressions in this section were adapted from the kubernetes-apps.yaml file in the Prometheus community Kubernetes Helm Charts repository on GitHub.

What's next