Administra métricas de GKE

Google Kubernetes Engine (GKE) facilita el envío de métricas a Cloud Monitoring. Cuando estén en Cloud Monitoring, las métricas pueden propagar paneles personalizados, generar alertas, crear objetivos de nivel de servicio, o los servicios de supervisión de terceros los recuperan mediante la API de Monitoring.

GKE proporciona dos fuentes de métricas:

  • Métricas del sistema: métricas de componentes esenciales del sistema, que describen recursos de bajo nivel, como CPU, memoria y almacenamiento.
  • Métricas de cargas de trabajo: métricas expuestas por cualquier carga de trabajo de GKE (como un CronJob o una implementación para una aplicación).

Métricas del sistema

De forma predeterminada, GKE recopila ciertas métricas emitidas por los componentes del sistema cuando se crea un clúster.

Tienes la opción de enviar métricas desde tu clúster de GKE a Cloud Monitoring. Si eliges enviar métricas a Cloud Monitoring, debes enviar métricas del sistema.

Todas las métricas del sistema de GKE se transfieren a Cloud Monitoring con el prefijo kubernetes.io.

Precios

Cloud Monitoring no cobra por la transferencia de las métricas del sistema de GKE. Obtén más información sobre los precios de Cloud Monitoring.

Configura la recopilación de métricas del sistema

Para habilitar la recopilación de métricas del sistema, pasa el valor SYSTEM a la marca --monitoring de los comandos gcloud container clusters create o gcloud container clusters update.

Para inhabilitar la recopilación de métricas del sistema, usa el valor NONE en la marca --monitoring. Si la recopilación de métricas del sistema está inhabilitada, la información básica como el uso de CPU, memoria y disco no está disponible para un clúster en la sección GKE de Cloud Console. Además, el panel de GKE de Cloud Monitoring no contiene información sobre el clúster.

Consulta Configura Cloud Operations para GKE a fin de obtener más detalles sobre la integración de Cloud Monitoring con GKE.

Lista de métricas del sistema

Las métricas del sistema incluyen métricas de componentes esenciales del sistema que son importantes para la funcionalidad principal de Kubernetes. Consulta una lista completa de las métricas del sistema.

Métricas de cargas de trabajo

Las métricas de cargas de trabajo de GKE son la forma recomendada de Google de supervisar las aplicaciones de Kubernetes con Cloud Monitoring.

GKE 1.20.8-gke.2100 o posterior ofrece una canalización de recopilación de métricas completamente administrada para recopilar métricas de estilo Prometheus expuestas por cualquier carga de trabajo de GKE (como un CronJob o una implementación para una aplicación) y envía esas métricas a Cloud Monitoring.

Todas las métricas que recopila la canalización de métricas de cargas de trabajo de GKE se transfieren a Cloud Monitoring con el prefijo workload.googleapis.com.

Los beneficios de las métricas de cargas de trabajo de GKE incluyen lo siguiente:

  • Configuración sencilla: Puedes comenzar a recopilar métricas con un solo comando de kubectl para implementar un recurso personalizado de PodMonitor. No se requiere la instalación manual de un agente.
  • Alto grado de configuración: Ajusta los extremos de recopilación, la frecuencia y otros parámetros.
  • Completamente administrado: Google mantiene la canalización para que puedas enfocarte en tus aplicaciones.
  • Controla los costos: Administra los costos de Cloud Monitoring con facilidad mediante el filtrado flexible de métricas.
  • Estándar abierto: Configura las métricas de cargas de trabajo con el recurso personalizado PodMonitor, que se modela después del recurso PodMonitor del operador de Prometheus.
  • Compatibilidad con HPA: Compatible con el adaptador de métricas personalizadas de Stackdriver para habilitar el escalamiento horizontal en las métricas personalizadas.
  • Mejor precio: Precios más intuitivos, predecibles y más bajos.
  • Compatibilidad con Autopilot: Admite clústeres de GKE Standard y GKE Autopilot.

Requisitos

Las métricas de cargas de trabajo de GKE requieren la versión del plano de control de GKE 1.20.8-gke.2100 o posterior y no son compatibles con las cargas de trabajo de GKE Windows.

Si habilitas la canalización de métricas de cargas de trabajo, también debes habilitar la recopilación de métricas del sistema.

Paso 1: Habilita la canalización de las métricas de carga de trabajo

Para habilitar la canalización de recopilación de métricas de cargas de trabajo en un clúster de GKE existente, sigue estos pasos:

CONSOLE

  1. En Google Cloud Console, ve a la lista de clústeres de GKE.

    Ir a Clústeres de Kubernetes

  2. Haz clic en el nombre del clúster.

  3. En la fila etiquetada “Cloud Monitoring”, haz clic en el ícono Editar.

  4. En el cuadro de diálogo “Editar Cloud Monitoring” que aparecerá, confirma que esté seleccionada la opción Habilitar Cloud Monitoring.

  5. En el menú desplegable, selecciona Cargas de trabajo.

  6. Haga clic en OK.

  7. Haz clic en Save Changes.

GCLOUD

  1. Abre una ventana de la terminal con el SDK de Cloud y la herramienta de línea de comandos de gcloud instalada. Una forma de hacerlo es mediante Cloud Shell:

  2. En Cloud Console, activa Cloud Shell.

    Activar Cloud Shell

    En la parte inferior de Cloud Console, se inicia una sesión de Cloud Shell en la que se muestra una ventana de línea de comandos. Cloud Shell es un entorno de shell que tiene el SDK de Cloud preinstalado, incluida la herramienta de línea de comandos de gcloud, y valores ya establecidos para el proyecto actual. La inicialización de la sesión puede tomar unos minutos.

  3. Ejecuta este comando:

    gcloud beta container clusters update [CLUSTER_ID] \
      --zone=[ZONE] \
      --project=[PROJECT_ID] \
      --monitoring=SYSTEM,WORKLOAD
    

    Incluir el valor WORKLOAD de la marca --monitoring de los comandos gcloud beta container clusters create o gcloud beta container clusters update habilita la canalización de recopilación de métricas de carga de trabajo.

Cuando se habilita la canalización de recopilación de métricas de cargas de trabajo, se implementa un agente de recopilación de métricas en cada nodo que puede recopilar métricas de aplicaciones que emiten las cargas de trabajo de Kubernetes.

Consulta Configura operaciones en la nube para GKE a fin de obtener más detalles sobre la integración de Cloud Monitoring en GKE.

Paso 2: Configura qué métricas se recopilan

1) Crea un recurso personalizado PodMonitor llamado my-pod-monitor.yaml:


apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  # POD_MONITOR_NAME is how you identify your PodMonitor
  name: [POD_MONITOR_NAME]
  # POD_NAMESPACE is the namespace where your workload is running, and the
  # namespace of your PodMonitor object
  namespace: [POD_NAMESPACE]
spec:
  # POD_LABEL_KEY and POD_LABEL_VALUE identify which pods to collect metrics
  # from. For example, POD_LABEL_KEY of app.kubernetes.io/name and
  # POD_LABEL_VALUE of mysql would collect metrics from all pods with the label
  # app.kubernetes.io/name=mysql
  selector:
    matchLabels:
      [POD_LABEL_KEY]: [POD_LABEL_VALUE]
  podMetricsEndpoints:
    # CONTAINER_PORT_NAME is the name of the port of the container to be scraped
    # Use the following command to list all ports exposed by the container:
    # kubectl get pod [POD_NAME] -n [POD_NAMESPACE] -o json | jq '.items[].spec.containers[].ports[]?' | grep -v null
    # If the port for your metrics does not have a name, modify your application's pod spec
    # to add a port name.
  - port: [CONTAINER_PORT_NAME]

2) Inicializa la credencial mediante la herramienta de línea de comandos de gcloud para configurar kubectl:

gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]

3) Implementa el recurso personalizado PodMonitor:

kubectl apply -f my-pod-monitor.yaml

Migrating

Si ya usas el sidecar de Stackdriver Prometheus, las métricas de cargas de trabajo de GKE proporcionan varias mejoras. Se recomienda que cambies a las métricas de cargas de trabajo de GKE para recopilar métricas emitidas por la aplicación. Consulta la guía de migración desde el archivo adicional de Stackdriver Prometheus a las métricas de carga de trabajo de GKE.

Precios

Cloud Monitoring cobra por la transferencia de las métricas de la carga de trabajo de GKE según la cantidad de muestras transferidas. Obtén más información sobre los precios de Cloud Monitoring.

Administra costos

Para administrar los costos, comienza por determinar qué métricas de cargas de trabajo son más valiosas para tus necesidades de supervisión. La canalización de métricas de cargas de trabajo de GKE proporciona controles detallados para lograr la compensación adecuada entre la captura de métricas detalladas y la conservación del costo bajo.

Muchas aplicaciones exponen una amplia variedad de métricas de Prometheus y, de forma predeterminada, la canalización de métricas de cargas de trabajo de GKE recopila todas las métricas de cada pod seleccionado cada 60 segundos.

Puedes usar las siguientes técnicas para reducir el costo de las métricas:

  1. Ajuste de la frecuencia de recopilación: Para reducir el costo de las métricas, recomendamos reducir la frecuencia de recopilación cuando corresponda. Por ejemplo, es posible que un KPI relevante para el negocio cambie lo suficientemente lento como a fin de que se pueda recopilar cada diez minutos. En el PodMonitor, configura el interval para controlar la frecuencia de recopilación.

  2. Filtra métricas: Identifica las métricas que no se usen en Cloud Monitoring y usa metricRelabelings para garantizar que solo las métricas útiles para los paneles, las alertas o los SLO se envíen a Cloud Monitoring.

Este es un ejemplo concreto de un recurso personalizado PodMonitor que usa ambas técnicas:

apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  name: prom-example
  namespace: gke-workload-metrics
spec:
  selector:
    matchLabels:
      app: example
  podMetricsEndpoints:
  - port: metrics
    path: /metrics
    scheme: http

    # (1) scrape metrics less frequently than the default (once every 60s)
    interval: 10m

    metricRelabelings:

    - # (2) drop the irrelevant metric named "foo" and all metrics
      # with the prefix "bar_"
      sourceLabels: [__name__]
      regex: foo|bar_.*
      action: drop

    - # (3) keep only metrics with a subset of values for a particular label
      sourceLabels: [region]
      regex: us-.*
      action: keep

Por último, hay muchos recursos disponibles para comprender el costo de las métricas de GKE transferidas a Cloud Monitoring y optimizar esos costos. Consulta la guía de optimización de costos para conocer más formas de reducir el costo de Cloud Monitoring.

Versiones anteriores de GKE

Para recopilar las métricas de la aplicación en un clúster con una versión del plano de control de GKE inferior a 1.20.8-gke.2100, usa el sidecar de Stackdriver Prometheus.

Soluciona problemas

Si las métricas de cargas de trabajo no están disponibles en Cloud Monitoring como se espera, aquí hay algunos pasos que puedes seguir para solucionar el problema.

Confirma que tu clúster cumple con los requisitos mínimos

Asegúrate de que tu clúster de GKE ejecute la versión del plano de control 1.20.8-gke.2100 o posterior. De lo contrario, actualiza el plano de control de tu clúster.

Confirma que las métricas de cargas de trabajo están habilitadas

Asegúrate de que tu clúster de GKE esté configurado para habilitar la canalización de recopilación de métricas de cargas de trabajo mediante los siguientes pasos:

CONSOLE

  1. En Google Cloud Console, ve a la lista de clústeres de GKE.

    Ir a Clústeres de Kubernetes

  2. Haz clic en el nombre del clúster.

  3. En el panel Detalles de tu clúster, confirma que “Workload” esté incluida en el estado de Cloud Monitoring. Si “Carga de trabajo” no se muestra aquí, habilita las métricas de carga de trabajo.

GCLOUD

  1. Abre una ventana de la terminal con el SDK de Cloud y gcloud instalado. Una forma de hacerlo es mediante Cloud Shell:

  2. En Cloud Console, activa Cloud Shell.

    Activar Cloud Shell

    En la parte inferior de Cloud Console, se inicia una sesión de Cloud Shell en la que se muestra una ventana de línea de comandos. Cloud Shell es un entorno de shell que tiene el SDK de Cloud preinstalado, incluida la herramienta de línea de comandos de gcloud, y valores ya establecidos para el proyecto actual. La inicialización de la sesión puede tomar unos minutos.

  3. Ejecuta este comando:

    gcloud container clusters describe [CLUSTER_ID] --zone=[ZONE]
    

    En el resultado de ese comando, busca la línea monitoringConfig:. Algunas líneas más tarde, confirman que la sección enableComponents: incluya WORKLOADS. Si WORKLOADS no se muestra aquí, habilita las métricas de cargas de trabajo.

Confirma que las métricas se recopilan de tu aplicación

Si no puedes ver las métricas de tu aplicación en Cloud Monitoring, los siguientes pasos pueden ayudarte a solucionar problemas. En estos pasos, se usa una app de ejemplo con fines de demostración, pero puedes aplicar los mismos pasos que se indican a continuación para solucionar problemas de cualquier aplicación.

En los primeros pasos que se indican a continuación, se implementa una app de ejemplo, que puedes usar para realizar pruebas. En los pasos restantes, se muestran los pasos que se deben seguir para solucionar problemas por los que las métricas de esa aplicación podrían no aparecer en Cloud Monitoring.

  1. Crea un archivo llamado prometheus-example-app.yaml que contenga lo siguiente:

    # This example application exposes prometheus metrics on port 1234.
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: prom-example
      name: prom-example
      namespace: gke-workload-metrics
    spec:
      selector:
        matchLabels:
          app: prom-example
      template:
        metadata:
          labels:
            app: prom-example
        spec:
          containers:
          - image: nilebox/prometheus-example-app@sha256:dab60d038c5d6915af5bcbe5f0279a22b95a8c8be254153e22d7cd81b21b84c5
            name: prom-example
            ports:
            - name: metrics-port
              containerPort: 1234
            command:
            - "/main"
            - "--process-metrics"
            - "--go-metrics"
    
  2. Inicializa la credencial mediante la herramienta de línea de comandos de gcloud para configurar kubectl:

    gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
    
  3. Crea el espacio de nombres gke-workload-metrics:

    kubectl create ns gke-workload-metrics
    
  4. Implementa la aplicación de ejemplo

    kubectl apply -f prometheus-example-app.yaml
    
  5. Para confirmar que la aplicación de ejemplo está en ejecución, ejecuta este comando:

    kubectl get pod -n gke-workload-metrics -l app=prom-example
    

    El resultado debe ser similar a este:

    NAME                            READY   STATUS    RESTARTS   AGE
    prom-example-775d8685f4-ljlkd   1/1     Running   0          25m
    
  6. Confirma que tu aplicación expone métricas como se espera

    Con uno de los pods que se muestran a partir del comando anterior, verifica que el extremo de métricas funcione de forma correcta:

    POD_NAME=prom-example-775d8685f4-ljlkd
    NAMESPACE=gke-workload-metrics
    PORT_NUMBER=1234
    METRICS_PATH=/metrics
    kubectl get --raw /api/v1/namespaces/$NAMESPACE/pods/$POD_NAME:$PORT_NUMBER/proxy/$METRICS_PATH
    

    Si usas la aplicación de ejemplo anterior, deberías recibir un resultado similar al siguiente:

    # HELP example_random_numbers A histogram of normally distributed random numbers.
    # TYPE example_random_numbers histogram
    example_random_numbers_bucket{le="0"} 501
    example_random_numbers_bucket{le="0.1"} 1.75933011554e+11
    example_random_numbers_bucket{le="0.2"} 3.50117676362e+11
    example_random_numbers_bucket{le="0.30000000000000004"} 5.20855682325e+11
    example_random_numbers_bucket{le="0.4"} 6.86550977647e+11
    example_random_numbers_bucket{le="0.5"} 8.45755380226e+11
    example_random_numbers_bucket{le="0.6"} 9.97201199544e+11
    ...
    
  7. Crea un archivo llamado my-pod-monitor.yaml que contenga lo siguiente:

    # Note that this PodMonitor is in the monitoring.gke.io domain,
    # rather than the monitoring.coreos.com domain used with the
    # Prometheus Operator.  The PodMonitor supports a subset of the
    # fields in the Prometheus Operator's PodMonitor.
    apiVersion: monitoring.gke.io/v1alpha1
    kind: PodMonitor
    metadata:
      name: example
      namespace: gke-workload-metrics
    # spec describes how to monitor a set of pods in a cluster.
    spec:
      # selector determines which pods are monitored.  Required
      # This example matches pods with the `app: prom-example` label
      selector:
        matchLabels:
          app: prom-example
      podMetricsEndpoints:
        # port is the name of the port of the container to be scraped.
      - port: metrics-port
        # path is the path of the endpoint to be scraped.
        # Default /metrics
        path: /metrics
        # scheme is the scheme of the endpoint to be scraped.
        # Default http
        scheme: http
        # interval is the time interval at which metrics should
        # be scraped. Default 60s
        interval: 20s
    
  8. Crea este recurso PodMonitor:

    kubectl apply -f my-pod-monitor.yaml
    

    Una vez que hayas creado el recurso PodMonitor, la canalización de métricas de cargas de trabajo de GKE detectará los pods adecuados y comenzará a recopilarlos de forma automática. La canalización enviará las métricas recopiladas a Cloud Monitoring.

  9. Confirma que la etiqueta y el espacio de nombres estén configurados correctamente en tu PodMonitor. Actualiza los valores de NAMESPACE y SELECTOR a continuación para reflejar las namespace y matchLabels en tu recurso personalizado PodMonitor. Luego, ejecuta este comando:

    NAMESPACE=gke-workload-metrics
    SELECTOR=app=prom-example
    kubectl get pods --namespace $NAMESPACE --selector $SELECTOR
    

    Deberías ver un resultado como el siguiente:

    NAME                            READY   STATUS    RESTARTS   AGE
    prom-example-7cff4db5fc-wp8lw   1/1     Running   0          39m
    
  10. Confirma que el PodMonitor esté en el estado Ready.

    Ejecuta este comando para mostrar todos los PodMonitor que instalaste en tu clúster:

    kubectl get podmonitor.monitoring.gke.io --all-namespaces
    

    Deberías ver un resultado similar a este:

    NAMESPACE              NAME      AGE
    gke-workload-metrics   example   2m36s
    

    Identifica el PodMonitor relevante del conjunto que se muestra y ejecuta este comando (reemplaza example en el comando que se muestra a continuación por el nombre del PodMonitor):

    kubectl describe podmonitor.monitoring.gke.io example --namespace gke-workload-metrics
    

    Examina los resultados que muestra kubectl describe y confirma que la condición “Listo” sea Verdadera. Si la condición “Listo” es Falsa, busca eventos que indiquen por qué no está listo.

  11. A continuación, confirmaremos que Cloud Monitoring recibe estas métricas. En la sección Cloud Monitoring de Google Cloud Console, ve al Explorador de métricas.

  12. En el campo Métrica, escribe example_requests_total.

  13. En el menú desplegable que aparece, selecciona workload.googleapis.com/example_requests_total.

    Esta métrica example_requests_total es una de las métricas de Prometheus que emite la aplicación de ejemplo.

    Si el menú desplegable no aparece o si no ves workload.googleapis.com/example_requests_total en el menú desplegable, vuelve a intentarlo en unos minutos.

    Todas las métricas están asociadas con el recurso de contenedor de Kubernetes (k8s_container) del que se recopilan. Puedes usar el campo Tipo de recurso del Explorador de métricas para seleccionar k8s_container. También puedes agrupar por etiquetas, como namespace_name o pod_name.

    Esta métrica se puede usar en cualquier lugar dentro de Cloud Monitoring o se puede consultar a través de la API de Cloud Monitoring. Por ejemplo, para agregar este gráfico a un panel existente o nuevo, haz clic en el botón Guardar gráfico en la esquina superior derecha y selecciona el panel deseado en una ventana de diálogo.

Comprueba los errores que se envían a la API de Cloud Monitoring

Las métricas enviadas a Cloud Monitoring deben permanecer dentro de los límites de métricas personalizadas. Los errores se mostrarán en los registros de auditoría de Cloud Monitoring.

Mediante el Explorador de registros de Cloud Logging, busca los registros con este filtro de registros (reemplaza PROJECT_ID por el nombre de tu proyecto):

resource.type="audited_resource"
resource.labels.service="monitoring.googleapis.com"
protoPayload.authenticationInfo.principalEmail=~".*-compute@developer.gserviceaccount.com"
resource.labels.project_id="[PROJECT_ID]"
severity>=ERROR

Ten en cuenta que esto mostrará errores para todas las operaciones de escritura en Cloud Monitoring del proyecto, no solo los de tu clúster.

Verifica tu cuota de transferencia de Cloud Monitoring

  1. Ve a la página Cuotas de la API de Cloud Monitoring.
  2. Selecciona el proyecto relevante.
  3. Expande la sección Solicitudes de transferencia de series temporales.
  4. Confirma que el Recuento de errores de superación de la cuota en “Solicitudes de transferencia de series temporales por minuto” sea 0. (Si este es el caso, el gráfico “Recuento de errores de superación de la cuota” indicará “No hay datos disponibles para el período seleccionado”).
  5. Si el porcentaje de uso máximo excede el 100%, considera seleccionar menos pods, seleccionar menos métricas o solicitar un límite de cuota más alto para la cuota monitoring.googleapis.com/ingestion_requests.

Confirma que el DaemonSet está implementado

Asegúrate de que las métricas de carga de trabajo de DaemonSet se implementen en tu clúster. Puedes validar que esto funciona como se espera mediante kubectl:

  1. Inicializa la credencial mediante la herramienta de línea de comandos de gcloud para configurar kubectl:

    gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
    
  2. Comprueba que el DaemonSet de métricas de cargas de trabajo esté presente y en buen estado. Ejecuta lo siguiente:

    kubectl get ds -n kube-system workload-metrics
    

    Si los componentes se implementaron de forma correcta, verás un resultado similar al siguiente:

    NAME               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   AGE
    workload-metrics   3         3         3       3            3           2m
    

    La cantidad de réplicas anteriores debe coincidir con la cantidad de nodos de GKE de Linux en tu clúster. Por ejemplo, un clúster con 3 nodos tendrá DESIRED = 3. Después de unos minutos, los números READY y AVAILABLE deben coincidir con el número DESIRED. De lo contrario, es posible que haya un problema con la implementación.

Otras métricas

Además de las métricas del sistema y las métricas de cargas de trabajo que se describieron antes, algunas métricas adicionales disponibles para un clúster de GKE son las siguientes: