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, el programador y el administrador del controlador de Kubernetes a Cloud Monitoring con Google Cloud Managed Service para Prometheus. En esta página también se describe cómo se formatean estas métricas cuando se escriben en Monitoring y cómo se consultan las métricas.

Antes de comenzar

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

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si deseas 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:

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 Google Cloud, gcloud CLI o Terraform.

Console

Puedes habilitar las métricas del plano de control para un clúster desde la pestaña Observabilidad del clúster o desde la pestaña Detalles del clúster. Cuando usas la pestaña Observabilidad, puedes obtener una vista previa de los gráficos y las métricas disponibles antes de habilitar el paquete de métricas.

Para habilitar las métricas del plano de control desde la pestaña Observabilidad del clúster, haz lo siguiente:

  1. En la consola de Google Cloud, ve a la página Clústeres de Kubernetes.

    Ir a clústeres de Kubernetes

    Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es Kubernetes Engine.

  2. Haz clic en el nombre del clúster y, luego, selecciona la pestaña Observabilidad.

  3. Selecciona Plano de control en la lista de funciones.

  4. Haz clic en Habilitar paquete.

    Si las métricas del plano de control ya están habilitadas, verás un conjunto de gráficos para las métricas del plano de control.

Para habilitar las métricas del plano de control desde la pestaña Detalles del clúster, haz lo siguiente:

  1. En la consola de Google Cloud, ve a la página Clústeres de Kubernetes.

    Ir a clústeres de Kubernetes

    Si usas la barra de búsqueda para encontrar esta página, selecciona el resultado cuyo subtítulo es Kubernetes Engine.

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

  3. En la fila Funciones etiquetada como 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 Componentes, selecciona los componentes del plano de control del que deseas recopilar métricas: Servidor de la API, Programador o Administrador de controladores.

  6. Haz clic en Aceptar.

  7. Haz clic en Guardar cambios.

gcloud

Actualiza tu clúster para recopilar las métricas que emiten el servidor de la API, el programador y el administrador de controladores de Kubernetes:

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

Reemplaza lo siguiente:

Terraform

A fin de configurar la colección de métricas del plano de control de Kubernetes mediante Terraform, consulta el bloque monitoring_config en el registro de Terraform para google_container_cluster. Para obtener información general sobre el uso de Google Cloud con Terraform, consulta Terraform con Google Cloud.

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 para cargar las 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 GKE Enterprise.

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

Formato de métrica

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 tiene 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 se pueden exportar desde Cloud Monitoring mediante la API de Cloud Monitoring. Debido a que todas las métricas del plano de control de Kubernetes se transfieren mediante Google Cloud Managed Service para Prometheus, se pueden consultar las métricas del plano de controlMediante el lenguaje de consulta de Prometheus (PromQL). También se pueden consultar a través del uso del 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 de 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 Google Cloud o en campos de PromQL de la API de Cloud Monitoring, usa el nombre de la métrica 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 las métricas del servidor de la API y también información adicional sobre cómo interpretar y usar las métricas.

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 en esta tabla deben tener el prefijo prometheus.googleapis.com/. Este prefijo se omitió en las entradas de la tabla.

Nombre de la métrica de PromQL Etapa de lanzamiento
Nombre de la métrica de Cloud Monitoring
Categoría, tipo, unidad
Recursos supervisados
Versión de GKE requerida		 Descripción
Etiquetas
apiserver_current_inflight_requests GA
apiserver_current_inflight_requests/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		Cantidad máxima del límite de solicitudes en curso usado actualmente de este apiserver por tipo de solicitud similar en el último segundo.

request_kind
apiserver_flowcontrol_current_executing_seats BETA
apiserver_flowcontrol_current_executing_seats/gauge
Gauge, Double, 1
prometheus_target
1.28.3+ 		Simultaneidad (cantidad de licencias) que ocupan las solicitudes que se ejecutan actualmente (etapa inicial para un WATCH, es decir, cualquier etapa) en el subsistema de prioridad y equidad de la API.

flow_schema
priority_level
apiserver_flowcontrol_current_inqueue_requests BETA
apiserver_flowcontrol_current_inqueue_requests/gauge
Gauge, Double, 1
prometheus_target
1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ para versiones secundarias anteriores) 		Cantidad de solicitudes pendientes actualmente en las colas del subsistema de prioridad y equidad de la API.

flow_schema
priority_level
apiserver_flowcontrol_nominal_limit_seats BETA
apiserver_flowcontrol_nominal_limit_seats/gauge
Gauge, Double, 1
prometheus_target
1.28.3+ (1.26.11+, 1.27.8+ para versiones secundarias anteriores) 		Cantidad nominal de licencias de ejecución configuradas para cada nivel de prioridad.

priority_level
apiserver_flowcontrol_rejected_requests_total BETA
apiserver_flowcontrol_rejected_requests_total/counter
Cumulative, Double, 1
prometheus_target
1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ para versiones secundarias anteriores) 		Cantidad de solicitudes que rechazó el subsistema de prioridad y equidad de la API.

flow_schema
priority_level
reason
apiserver_flowcontrol_request_wait_duration_seconds BETA
apiserver_flowcontrol_request_wait_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ para versiones secundarias anteriores) 		La cantidad de tiempo que una solicitud estuvo en espera en su cola.

execute
flow_schema
priority_level
apiserver_request_duration_seconds GA
apiserver_request_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.23.6+ 		Distribución de latencia de respuesta en segundos para cada verbo, valor de ejecución de prueba, grupo, versión, recurso, subrecurso, alcance y componente.

component
dry_run
group
resource
scope
subresource
verb
version
apiserver_request_total GA
apiserver_request_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		Contador de solicitudes de apiserver desglosadas para cada verbo, valor de ejecución de prueba, grupo, versión, recurso, permiso, componente y código de respuesta HTTP.

code
component
dry_run
group
resource
scope
subresource
verb
version
apiserver_response_sizes GA
apiserver_response_sizes/histogram
Cumulative, Distribution, 1
prometheus_target
1.22.13+ 		Distribución de tamaño de las respuestas en bytes para cada grupo, versión, verbo, recurso, subrecurso, alcance y componente.

component
group
resource
scope
subresource
verb
version
apiserver_storage_objects GA
apiserver_storage_objects/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		Cantidad de objetos almacenados en el momento de la última verificación dividida por tipo.

resource
apiserver_admission_controller_admission_duration_seconds GA
apiserver_admission_controller_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.23.6+ 		Histograma de latencia del controlador de admisión en segundos, identificado por nombre y desglosado para cada operación y recurso y tipo de API (validación o admisión).

name
operation
rejected
type
apiserver_admission_step_admission_duration_seconds GA
apiserver_admission_step_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.22.13+ 		Histograma de latencia de paso secundario de admisión en segundos, desglosado para cada operación y recurso de API y tipo de paso (validar o admitir).

operation
rejected
type
apiserver_admission_webhook_admission_duration_seconds GA
apiserver_admission_webhook_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.22.13+ 		Histograma de latencia de webhook de admisión en segundos, identificado por nombre y desglosado para cada operación y recurso de API y tipo (validación o admisión).

name
operation
rejected
type

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 las siguientes tareas:

  • La autenticación y autorización de la solicitud.
  • Llamar a los webhooks de terceros y del sistema asociados con la solicitud.
  • Recuperar el objeto solicitado de una caché en memoria (para solicitudes que especifican un parámetro URL resourceVersion) o de etcd (para todas las demás solicitudes).
  • Puedes usar las etiquetas group, version, resource y subresource a fin de identificar de forma única una solicitud lenta para una investigación más detallada.
  • Escribir la respuesta al cliente y recibir 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 específicas de latencia.

apiserver_admission_controller_admission_duration_seconds

Esta métrica mide la latencia en 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. Por lo general, la métrica apiserver_admission_webhook_admission_duration_seconds es la métrica 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 usarlo para determinar las tasas de éxito y de errores de tus solicitudes. Para obtener más información sobre el uso de esta métrica, consulta Tráfico y tasa de error.

Esta métrica tiene una cardinalidad muy alta. Cuando uses esta métrica, 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, también, identificar posibles filtraciones 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 de forma activa en el último período de un 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 brindarte 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 está sobrecargado, aumenta la latencia de la solicitud. 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 mediante la etiqueta verb o resource.

El límite superior sugerido para una llamada de un solo recurso, como GET, POST o PATCH, es de 1 segundo. El límite superior sugerido para las llamadas 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 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:

  • El plano de control de Kubernetes puede estar 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 única 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 son lentos o no responden. La latencia en el webhook de admisión puede causar demoras en la programación del trabajo.

    • Para consultar la latencia del webhook del percentil 99 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. puedes ajustar esta consulta si modificas el valor 0.99.

    • Los webhooks externos tienen un límite de tiempo de espera de alrededor de 10 segundos. Puedes configurar 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 ejecuta en un dispositivo como un teléfono celular, pero es poco probable que este ejecute en una red de Compute Engine.
    • El cliente cerró de forma inesperada, pero la conexión TCP tiene un tiempo de espera 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 API de Priority and Fairness 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 que no se realizaron de forma correcta, filtra la etiqueta code por los valores 4xx y 5xx mediante 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 mediante la siguiente consulta de PromQL:

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

  • Para consultar las solicitudes rechazadas por el servidor de la API por instancia del plano de control de Kubernetes, filtra la etiqueta code por el valor 429 (http.StatusTooManyRequests) mediante 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 en el sistema mediante 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 por 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 equidad y prioridad 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 en esta tabla deben tener el prefijo prometheus.googleapis.com/. Este prefijo se omitió en las entradas de la tabla.

Nombre de la métrica de PromQL Etapa de lanzamiento
Nombre de la métrica de Cloud Monitoring
Categoría, tipo, unidad
Recursos supervisados
Versión de GKE requerida		 Descripción
Etiquetas
scheduler_pending_pods GA
scheduler_pending_pods/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		Cantidad de Pods pendientes, por tipo de cola. “activos” se refiere a la cantidad de Pods en activeQ; “retirados” se refiere a la cantidad de Pods en backoffQ; “no programable” se refiere a la cantidad de Pods unschedulablePods.

queue
scheduler_pod_scheduling_duration_seconds OBSOLETO
scheduler_pod_scheduling_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.25.1 a 1.29 (1.22.17-gke.3100+ , 1.23.11+ y 1.24.5+ para versiones secundarias anteriores) 		[Obsoleto en la versión 1.29; se quitó en la versión 1.30 y se reemplazó por scheduler_pod_scheduling_sli_duration_seconds].] Latencia E2e para un Pod que está programado, lo que puede incluir varios intentos de programación.

attempts
scheduler_pod_scheduling_sli_duration_seconds BETA
scheduler_pod_scheduling_sli_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.30+ 		Latencia E2e de un Pod que está programado, desde el momento en que el Pod ingresa a la cola de programación, lo que puede implicar varios intentos de programación.

attempts
scheduler_preemption_attempts_total GA
scheduler_preemption_attempts_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		Total de intentos de interrupción en el clúster hasta ahora
scheduler_preemption_victims GA
scheduler_preemption_victims/histogram
Cumulative, Distribution, 1
prometheus_target
1.22.13+ 		Cantidad de víctimas de interrupciones seleccionadas
scheduler_scheduling_attempt_duration_seconds GA
scheduler_scheduling_attempt_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.23.6+ 		Latencia de los intentos de programación en segundos (algoritmo de programación + vinculación).

profile
result
scheduler_schedule_attempts_total GA
scheduler_schedule_attempts_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		Cantidad de intentos de programación de Pods, por resultado. “no programable” se refiere a un Pod que no se pudo programar, mientras que “error” se refiere a un problema interno del programador.

profile
result

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 en tu programador. Aumentar los valores en esta métrica puede indicar problemas de asignación de recursos. El programador tiene tres colas y esta métrica informa la cantidad de solicitudes pendientes por cola. Las siguientes colas son compatibles:

  • Cola active
    • El conjunto de pods que el programador intenta programar; el pod con mayor prioridad se encuentra en el encabezado de la cola.
  • Cola backoff
    • 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 cola de active para otro intento de programación. Para obtener más información sobre la administración de la cola backoff, consulta la solicitud de implementación, problema 75417 de Kubernetes.

  • Conjunto unschedulable

    • Es el conjunto de Pods que el programador intentó programar, pero que se determinó que no son programables. La ubicación en esta cola puede indicar problemas de preparación o compatibilidad 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, los pods nuevos no se pueden programar y se colocan en la cola unscheduled.

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

    • Las afinidades definen reglas para asignar los Pods a los nodos. El uso de reglas de afinidad o antiafinidad puede ser un motivo de un aumento en los 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 cola 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 por el resultado: programado, no programable o con error. La duración ocurre desde el momento en que el programador recoge un pod hasta el momento en que el programador localiza un nodo y coloca el pod en el nodo, determina que el pod no se puede programar o encuentra un error. La duración de la programación incluye el tiempo en el proceso de programación y el tiempo de vinculación. La vinculación es el proceso en el cual el programador comunica su asignación de nodo 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; 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, entonces el programador está disponible. Puedes usar la etiqueta result para determinar el éxito; los Pods podrían ser scheduled o unschedulable.

Esta métrica tiene una correlación muy fuerte con la métrica scheduler_pending_pods: cuando hay muchos Pods pendientes, es posible que veas muchos intentos de programarlos. Para obtener más información, consulta Problemas de recursos.

Esta métrica no aumenta si el programador no tiene pods para programar, lo cual puede ser el caso si tienes un programador secundario personalizado.

scheduler_preemption_attempts_total y scheduler_preemptions_victims

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

Es posible que tengas pods de mayor prioridad que no se pueden programar porque no hay espacio para ellos. En este caso, el programador libera recursos mediante la interrupción de uno o más pods 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 cuenta los Pods seleccionados para la interrupción.

La cantidad de intentos de interrupción tiene una correlación muy fuerte 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 darte estadísticas sobre el rendimiento de tu programador:

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 deseas saber cuándo el programador está atascado o ejecutándose lentamente.

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

  • Cuando el programador se ejecuta con lentitud, 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 muestra la cantidad de Pods pendientes por cola 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.

      Recomendamos observar 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 recursos suficientes. Si el valor de la métrica scheduler_preemption_attempts_total aumenta, verifica el valor de scheduler_preemption_victims mediante 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 reducidas o cambiar el selector de nodos.

  • Si la cantidad de víctimas de interrupción no aumenta, no hay Pods restantes con 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, hay Pods de prioridad más alta que esperan programarse, por lo que el programador interrumpe algunos de los Pods en ejecución. Las métricas de interrupción no te indican si los Pods de mayor prioridad se programaron con éxito.

    Para determinar si los pods de mayor prioridad están programados, 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 temporales 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 recursos suficientes en tu clúster, estos aumentos son temporales. Si la cantidad de Pods pendientes no disminuye, haz lo siguiente:

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

Si no se pueden programar Pods debido a recursos 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 en esta tabla deben tener el prefijo prometheus.googleapis.com/. Este prefijo se omitió en las entradas de la tabla.

Nombre de la métrica de PromQL Etapa de lanzamiento
Nombre de la métrica de Cloud Monitoring
Categoría, tipo, unidad
Recursos supervisados
Versión de GKE requerida		 Descripción
Etiquetas
node_collector_evictions_total GA
node_collector_evictions_total/counter
Cumulative, Double, 1
prometheus_target
1.24+ 		Cantidad de expulsiones de nodos que ocurrieron desde que se inició la instancia actual de NodeController.

zone