Recopila y visualiza las métricas del plano de control

En esta página, se describe cómo configurar un clúster de Google Kubernetes Engine (GKE) para enviar métricas emitidas por el servidor de la API de Kubernetes, y el programador y el administrador del controlador a Cloud Monitoring con Google Cloud Managed Service para Prometheus. En esta página, también se explica cómo se formatean estas métricas cuando se escriben en Monitoring y cómo se consultan.

Antes de empezar

Antes de empezar, asegúrate de haber realizado las siguientes tareas:

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Si quieres usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.

Requisitos

Para enviar métricas emitidas por los componentes del plano de control de Kubernetes a Cloud Monitoring, se deben cumplir los siguientes requisitos:

• El clúster debe tener habilitadas las métricas del sistema.

Configura la recopilación de métricas del plano de control

Puedes habilitar las métricas del plano de control en un clúster de GKE existente con la consola de Trusted Cloud , gcloud CLI o Terraform.

gcloud container clusters update CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --monitoring=SYSTEM,API_SERVER,SCHEDULER,CONTROLLER_MANAGER

Cuota

Las métricas del plano de control consumen la cuota de “solicitudes de transferencia de series temporales por minuto” de la API de Cloud Monitoring. Antes de habilitar los paquetes de métricas, verifica tu uso máximo reciente de esa cuota. Si tienes muchos clústeres en el mismo proyecto o ya te acercaste al límite de esa cuota, puedes solicitar un aumento del límite de cuota antes de habilitar cualquiera de los paquetes de observabilidad.

Precios

Las métricas del plano de control de GKE usan Google Cloud Managed Service para Prometheus con el objetivo de cargar métricas en Cloud Monitoring. Cloud Monitoring cobra por la transferencia de estas métricas según la cantidad de muestras transferidas. Sin embargo, estas métricas son sin costo para los clústeres registrados que pertenecen a un proyecto que tiene habilitada la edición de GKE Enterprise.

Para obtener más información, consulta los precios de Cloud Monitoring.

Formato de métricas

Todas las métricas del plano de control de Kubernetes escritas en Cloud Monitoring usan el tipo de recurso prometheus_target. Cada nombre de métrica tiene el prefijo prometheus.googleapis.com/ y un sufijo que indica el tipo de métrica de Prometheus, como /gauge, /histogram o /counter. De lo contrario, cada nombre de métrica es idéntico al nombre de la métrica que expone Kubernetes de código abierto.

Exporta desde Cloud Monitoring

Las métricas del plano de control de Kubernetes se pueden exportar desde Cloud Monitoring con la API de Cloud Monitoring. Debido a que todas las métricas del plano de control de Kubernetes se transfieren con Google Cloud Managed Service para Prometheus, las métricas del plano de control se pueden consultar con el lenguaje de consulta de Prometheus (PromQL). También se pueden consultar con el lenguaje de consulta de Monitoring (MQL).

Consulta métricas

Cuando consultas las métricas del plano de control de Kubernetes, el nombre que usas depende de si usas funciones basadas en PromQL o Cloud Monitoring, como MQL o la interfaz controlada por menú del Explorador de métricas.

En las siguientes tablas de métricas del plano de control de Kubernetes, se muestran dos versiones de cada nombre de métrica:

• Nombre de la métrica de PromQL: Cuando usas PromQL en páginas de Cloud Monitoring de la consola de Trusted Cloud o en campos de PromQL de la API de Cloud Monitoring, usa el nombre de la métrica de PromQL.
• Nombre de la métrica de Cloud Monitoring Cuando uses otras funciones de Cloud Monitoring, usa el nombre de la métrica de Cloud Monitoring en las tablas que aparecen a continuación. Este nombre debe tener el prefijo prometheus.googleapis.com/, que se omitió en las entradas de la tabla.

Métricas del servidor de la API

En esta sección, se proporciona una lista de métricas del servidor de la API y, también, información adicional sobre cómo interpretarlas y usarlas.

Lista de métricas del servidor de la API

Cuando las métricas del servidor de la API están habilitadas, todas las métricas que se muestran en la siguiente tabla se exportan a Cloud Monitoring en el mismo proyecto que el clúster de GKE.

Los nombres de las métricas de Cloud Monitoring que figuran en esta tabla deben tener el prefijo prometheus.googleapis.com/. Sin embargo, el prefijo se omitió en las entradas de la tabla.

En las siguientes secciones, se proporciona información adicional sobre las métricas del servidor de la API.

apiserver_request_duration_seconds

Usa esta métrica para supervisar la latencia en el servidor de la API. La duración de la solicitud que registra esta métrica incluye todas las fases del procesamiento de solicitudes, desde el momento en que se recibe la solicitud hasta que el servidor completa su respuesta al cliente. Específicamente, incluye el tiempo dedicado a lo siguiente:

• La autenticación y autorización de la solicitud
• La llamada a los webhooks de terceros y del sistema asociados a la solicitud
• La recuperación del objeto solicitado de una caché en memoria (para solicitudes que especifican un parámetro de URL resourceVersion) o de la base de datos de estado del clúster basada en etcd o Spanner llamando a la API de etcd (para el resto de las solicitudes)
• Se pueden usar las etiquetas group, version, resource y subresource para identificar de forma inequívoca una solicitud lenta para una investigación más detallada
• La escritura de la respuesta al cliente y la recepción de su respuesta

Para obtener más información sobre el uso de esta métrica, consulta Latencia.

Esta métrica tiene una cardinalidad muy alta. Cuando uses esta métrica, debes usar filtros o grupos para encontrar fuentes de latencia específicas.

apiserver_admission_controller_admission_duration_seconds

Esta métrica mide la latencia en los webhooks de admisión integrados, no en webhooks de terceros. Para diagnosticar problemas de latencia con webhooks de terceros, usa la métrica apiserver_admission_webhook_admission_duration_seconds.

apiserver_admission_webhook_admission_duration_seconds y
apiserver_admission_step_admission_duration_seconds

Estas métricas miden la latencia en webhooks de admisión externos de terceros. En general, la métrica apiserver_admission_webhook_admission_duration_seconds es la más útil. Para obtener más información sobre el uso de esta métrica, consulta Latencia.

apiserver_request_total

Usa esta métrica para supervisar el tráfico de solicitudes en tu servidor de la API. También puedes usarla para determinar las tasas de éxito y de errores de las solicitudes. Para obtener más información sobre el uso de esta métrica, consulta Tráfico y tasa de errores.

Esta métrica tiene una cardinalidad muy alta. Cuando la uses, debes usar filtros o grupos para identificar las fuentes de errores.

apiserver_storage_objects

Usa esta métrica para detectar la saturación del sistema y posibles fugas de recursos. Para obtener más información, consulta Saturación.

apiserver_current_inflight_requests

Esta métrica registra la cantidad máxima de solicitudes que se entregaron activamente en el período del último segundo. Para obtener más información, consulta Saturación.

La métrica no incluye solicitudes de larga duración como “watch”.

Supervisa el servidor de la API

Las métricas del servidor de la API pueden aportar estadísticas sobre los indicadores principales del estado del sistema:

• Latencia: ¿Cuánto tiempo se tarda en entregar una solicitud?
• Tráfico: ¿Cuánta demanda experimenta el sistema?
• Tasa de errores: ¿Con qué frecuencia fallan las solicitudes?
• Saturación: ¿Qué tan completo está el sistema?

En esta sección, se describe cómo usar las métricas del servidor de la API para supervisar el estado de tu servidor de la API.

Latencia

Cuando el servidor de la API se sobrecarga, aumenta la latencia de las solicitudes. Para medir la latencia de las solicitudes al servidor de la API, usa la métrica apiserver_request_duration_seconds. Para identificar la fuente de la latencia de manera más específica, puedes agrupar las métricas con la etiqueta verb o resource.

El límite superior sugerido para una llamada a un solo recurso, como GET, POST o PATCH, es de un segundo. El límite superior sugerido para las llamadas a LIST con alcance de clúster y espacio de nombres es de 30 segundos. Los SLO definidos por la comunidad de Kubernetes de código abierto establecen las expectativas de límite superior. Para obtener más información, consulta los detalles de SLI/SLO de latencia de las llamadas a la API.

Si el valor de la métrica apiserver_request_duration_seconds aumenta más allá de la duración esperada, investiga las siguientes causas posibles:

• Es posible que el plano de control de Kubernetes esté sobrecargado. Para verificarlo, consulta las métricas apiserver_request_total y apiserver_storage_objects.
  • Usa la etiqueta code para determinar si las solicitudes se procesan de forma correcta. Para obtener información sobre los valores posibles, consulta Códigos de estado HTTP.
  • Usa las etiquetas group, version, resource y subresource para identificar de forma inequívoca una solicitud.

• Un webhook de admisión de terceros es lento o no responde. Si el valor de la métrica apiserver_admission_webhook_admission_duration_seconds aumenta, significa que algunos de tus webhooks de admisión de terceros o definidos por el usuario están lentos o no responden. La latencia en el webhook de admisión puede causar demoras en la programación del trabajo.

  • Para consultar el percentil 99 de la latencia de webhook por instancia del plano de control de Kubernetes, usa la siguiente consulta de PromQL:

    sum by (instance) (histogram_quantile(0.99, rate(apiserver_admission_webhook_admission_duration_seconds_bucket{cluster="CLUSTER_NAME"}[1m])))
    

    Te recomendamos que observes también los percentiles 50, 90, 95 y 99.9. Esta consulta se puede ajustar modificando el valor 0.99.

  • Los webhooks externos tienen un límite de tiempo de espera de alrededor de 10 segundos. Puedes establecer políticas de alertas en la métrica apiserver_admission_webhook_admission_duration_seconds para recibir alertas cuando te acerques al tiempo de espera del webhook.

  • También puedes agrupar la métrica apiserver_admission_webhook_admission_duration_seconds en la etiqueta name para diagnosticar posibles problemas con webhooks específicos.

• Estás enumerando muchos objetos. Se espera que la latencia de las llamadas LIST aumente a medida que aumenta la cantidad de objetos de un tipo determinado (el tamaño de respuesta).

• Problemas del cliente:

  • Es posible que el cliente no tenga suficientes recursos para recibir respuestas de manera oportuna. Para verificarlo, consulta las métricas de uso de CPU del pod del cliente.
  • El cliente tiene una conexión de red lenta. Esto puede suceder cuando el cliente se ejecuta en un dispositivo como un teléfono celular, pero es poco probable que se ejecute en una red de Compute Engine.
  • El cliente cerró de forma inesperada, pero la conexión TCP tiene un tiempo de espera establecido en decenas de segundos. Antes de que se agote el tiempo de espera de la conexión, se bloquean los recursos del servidor, lo que puede aumentar la latencia.

Para obtener más información, consulta Prácticas recomendadas para usar la prioridad y equidad de la API en la documentación de Kubernetes.

Tráfico y tasa de error

Para medir el tráfico y la cantidad de solicitudes correctas y fallidas en el servidor de la API, usa la métrica apiserver_request_total. Por ejemplo, para medir el tráfico del servidor de la API por instancia del plano de control de Kubernetes, usa la siguiente consulta de PromQL:

sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME"}[1m]))

• Para consultar las solicitudes incorrectas, filtra la etiqueta code por los valores 4xx y 5xx con la siguiente consulta de PromQL:

  sum(rate(apiserver_request_total{code=~"[45].."}[5m]))
  

• Para consultar las solicitudes correctas, filtra la etiqueta code por los valores 2xx con la siguiente consulta de PromQL:

  sum(rate(apiserver_request_total{code=~"2.."}[5m]))
  

• Para consultar las solicitudes que rechaza el servidor de la API por instancia del plano de control de Kubernetes, filtra la etiqueta code por el valor 429 (http.StatusTooManyRequests) con la siguiente consulta de PromQL:

  sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME", code="429"}[1m]))
  

Saturación

Puedes medir la saturación del sistema con las métricas apiserver_current_inflight_requests y apiserver_storage_objects .

Si el valor de la métrica apiserver_storage_objects aumenta, es posible que tengas un problema con un controlador personalizado que crea objetos, pero no los borra. Puedes filtrar o agrupar la métrica en función de la etiqueta resource para identificar el recurso que experimenta el aumento.

Evalúa la métrica apiserver_current_inflight_requests de acuerdo con la configuración de la prioridad y equidad de la API; esta configuración afecta la forma en que se priorizan las solicitudes, por lo que no puedes extraer conclusiones solo de los valores de la métrica. Para obtener más información, consulta Prioridad y equidad de la API.

Métricas del programador

En esta sección, se proporciona una lista de las métricas del programador y, también, información adicional sobre cómo interpretar y usar las métricas.

Lista de métricas del programador

Cuando las métricas del programador están habilitadas, todas las métricas que se muestran en la siguiente tabla se exportan a Cloud Monitoring en el mismo proyecto que el clúster de GKE.

Los nombres de las métricas de Cloud Monitoring que figuran en esta tabla deben tener el prefijo prometheus.googleapis.com/. Sin embargo, el prefijo se omitió en las entradas de la tabla.

En las siguientes secciones, se proporciona información adicional sobre las métricas del servidor de la API.

scheduler_pending_pods

Puedes usar la métrica scheduler_pending_pods para supervisar la carga del programador. Aumentar los valores de esta métrica puede indicar problemas de asignación de recursos. El programador tiene tres filas, y esta métrica informa la cantidad de solicitudes pendientes por fila. Se admiten las siguientes filas:

• Fila active
  • Es el conjunto de Pods que el programador intenta programar; el Pod con mayor prioridad se encuentra en el principio de la fila.
• Fila backoff
  • Es el conjunto de Pods que no se pudieron programar la última vez que el programador intentó, pero que podrían programarse la próxima vez.
  • Los Pods en esta cola deben esperar un período de retirada (un máximo de 10 segundos), después del cual se vuelven a mover a la fila active para otro intento de programación. Para obtener más información sobre la administración de la fila backoff, consulta la solicitud de implementación, problema de Kubernetes 75417.

• Conjunto unschedulable

  • Es el conjunto de Pods que el programador intentó programar, pero que se determinó que no es programable. La ubicación en esta fila puede indicar problemas de compatibilidad o preparación con tus nodos o la configuración de tus selectores de nodos.

    Cuando las restricciones de recursos impiden que se programen Pods, los Pods no están sujetos al control de retirada. En cambio, cuando un clúster está lleno, no se pueden programar Pods nuevos y se colocan en la fila unscheduled.

  • La presencia de Pods no programados podría indicar que no tienes recursos suficientes o que tienes un problema de configuración de nodos. Los Pods se mueven a la fila backoff o active después de los eventos que cambian el estado del clúster. Los Pods en esta fila indican que no cambió nada en el clúster que haría que los Pods se puedan programar.

  • Las afinidades definen reglas sobre cómo se asignan los Pods a los nodos. El uso de reglas de afinidad o antiafinidad puede ser un motivo del aumento de Pods no programados.

  • Algunos eventos, como PVC/Service ADD/UPDATE, la finalización de un Pod o el registro de nodos nuevos, mueven algunos o todos los Pods no programados a la fila backoff o active. Para obtener más información, consulta Problema de Kubernetes 81214.

Para obtener más información, consulta Latencia del programador y Problemas de recursos.

scheduler_scheduling_attempt_duration_seconds

Esta métrica mide la duración de un solo intento de programación dentro del programador y se desglosa según el resultado: programado, no programable o con error. La duración abarca desde el momento en que el programador recoge un Pod hasta que localiza un nodo y coloca el Pod en él, determina que el Pod no se puede programar o encuentra un error. La duración de la programación incluye el tiempo del proceso de programación y el tiempo de vinculación. La vinculación es el proceso en el que el programador comunica su asignación de nodos al servidor de la API. Para obtener más información, consulta Latencia del programador.

Esta métrica no captura el tiempo que el Pod pasa en la validación o el control de admisión.

Para obtener más información sobre la programación, consulta Programa un Pod.

scheduler_schedule_attempts_total

Esta métrica mide la cantidad de intentos de programación, y cada intento de programar un Pod aumenta el valor. Puedes usar esta métrica para determinar si el programador está disponible: si el valor aumenta, el programador está operativo. Puedes usar la etiqueta result para determinar el éxito; los Pods pueden ser scheduled o unschedulable.

Esta métrica se correlaciona en gran medida con la métrica scheduler_pending_pods: cuando hay muchos Pods pendientes, es normal que haya muchos intentos de programar los Pods. Para obtener más información, consulta Problemas de recursos.

Esta métrica no aumenta si el programador no tiene Pods para programar, lo que puede ocurrir si tienes un programador secundario personalizado.

scheduler_preemption_attempts_total y scheduler_preemptions_victims

Puedes usar las métricas de interrupción para determinar si necesitas agregar recursos.

Es posible que tengas Pods de mayor prioridad que no se puedan programar porque no hay espacio para ellos. En este caso, el programador libera recursos interrumpiendo uno o más Pods que están en ejecución en un nodo. La métrica scheduler_preemption_attempts_total realiza un seguimiento de la cantidad de veces que el programador intentó interrumpir Pods.

La métrica scheduler_preemptions_victims registra los Pods seleccionados para la interrupción.

La cantidad de intentos de interrupción tiene una gran correlación con el valor de la métrica scheduler_schedule_attempts_total cuando el valor de la etiqueta result es unschedulable. Los dos valores no son equivalentes. Por ejemplo, si un clúster tiene 0 nodos, no hay intentos de interrupción, pero puede haber intentos de programación que fallen.

Para obtener más información, consulta Problemas de recursos.

Supervisa el programador

Las métricas del programador pueden brindarte estadísticas sobre el rendimiento de tu programador:

• Latencia del programador: ¿Se está ejecutando el programador? ¿Cuánto tarda en programar los Pods?
• Problemas de recursos: ¿Los intentos de programar Pods alcanzan las restricciones de recursos?

En esta sección, se describe cómo usar la métrica del programador para supervisar tu programador.

Latencia del programador

La tarea del programador es garantizar que tus Pods se ejecuten, por lo que debes saber cuándo el programador está atascado o ejecutándose lento.

• Para verificar que el programador se esté ejecutando y programando Pods, usa la métrica scheduler_schedule_attempts_total.

• Cuando el programador se ejecuta lento, investiga las siguientes causas posibles:

  • La cantidad de Pods pendientes está aumentando. Usa la métrica scheduler_pending_pods para supervisar la cantidad de Pods pendientes. La siguiente consulta de PromQL devuelve la cantidad de Pods pendientes por fila en un clúster:

    sum by (queue)
    (delta(scheduler_pending_pods{cluster="CLUSTER_NAME"}[2m]))
    

  • Los intentos individuales de programar Pods son lentos. Usa la métrica scheduler_scheduling_attempt_duration_seconds para supervisar la latencia de los intentos de programación.

    Te recomendamos que observes esta métrica al menos en los percentiles 50 y 95. La siguiente consulta de PromQL recupera los valores del percentil 95, pero se puede ajustar:

    sum by (instance) (histogram_quantile(0.95, rate(
    scheduler_scheduling_attempt_duration_seconds_bucket{cluster="CLUSTER_NAME"}[5m])))
    

Problemas de recursos

Las métricas del programador también pueden ayudarte a evaluar si tienes suficientes recursos. Si el valor de la métrica scheduler_preemption_attempts_total aumenta, verifica el valor de scheduler_preemption_victims con la siguiente consulta de PromQL:

scheduler_preemption_victims_sum{cluster="CLUSTER_NAME"}

La cantidad de intentos de interrupción y la cantidad de víctimas de interrupciones aumentan cuando hay Pods de mayor prioridad para programar. Las métricas de interrupción no indican si los Pods de prioridad alta que activaron las interrupciones se programaron. Por lo tanto, cuando veas aumentos en el valor de las métricas de interrupción, también puedes supervisar el valor de la métrica scheduler_pending_pods. Si la cantidad de Pods pendientes también aumenta, es posible que no tengas recursos suficientes para manejar los Pods de mayor prioridad. Es posible que debas escalar verticalmente los recursos disponibles, crear Pods nuevos con reclamaciones de recursos reducidos o cambiar el selector de nodos.

• Si la cantidad de víctimas de interrupciones no aumenta, significa que no quedan Pods de prioridad baja que se puedan quitar. En este caso, considera agregar más nodos para que se puedan asignar los Pods nuevos.

• Si la cantidad de víctimas de interrupción aumenta, significa que hay Pods de mayor prioridad en espera para programarse, por lo que el programador está interrumpiendo algunos de los Pods en ejecución. Las métricas de interrupción no indican si los Pods de mayor prioridad se programaron correctamente.

  Para determinar si se están programando los Pods de mayor prioridad, busca valores decrecientes de la métrica scheduler_pending_pods. Si el valor de esta métrica aumenta, es posible que debas agregar más nodos.

Es posible que veas aumentos repentinos en los valores de la métrica scheduler_pending_pods cuando se vayan a programar las cargas de trabajo en el clúster, por ejemplo, durante eventos como actualizaciones o escalamientos. Si tienes suficientes recursos en tu clúster, estos aumentos repentinos son temporales. Si la cantidad de Pods pendientes no disminuye, haz lo siguiente:

• Verifica que los nodos no estén acordonados, ya que estos no aceptan Pods nuevos.
• Verifica las siguientes directivas de programación, que pueden estar mal configuradas y hacer que un Pod no sea programable:
  • Afinidad y selector de nodos
  • Taints y tolerancias
  • Restricciones de distribución de topología de Pods

Si los Pods no se pueden programar debido a que los recursos son insuficientes, considera liberar algunos de los nodos existentes o aumentar la cantidad de nodos.

Métricas del administrador de controladores

Cuando las métricas del administrador de controladores están habilitadas, todas las métricas que se muestran en la siguiente tabla se exportan a Cloud Monitoring en el mismo proyecto que el clúster de GKE.

Los nombres de las métricas de Cloud Monitoring que figuran en esta tabla deben tener el prefijo prometheus.googleapis.com/. Sin embargo, el prefijo se omitió en las entradas de la tabla.