Recoger y ver 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, el programador y el gestor de controladores a Cloud Monitoring mediante Google Cloud Managed Service para Prometheus. En esta página también se describe cómo se da formato a estas métricas cuando se escriben en Monitoring y cómo se consultan.

Antes de empezar

Antes de empezar, asegúrate de que has 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, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando gcloud components update.

Requisitos

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

Configurar la recogida de métricas del plano de control

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

Consola

Puedes habilitar las métricas del plano de control de 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 previsualizar 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 Google Cloud consola, ve a la página Clústeres de Kubernetes:

    Ve a Clústeres de Kubernetes.

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

  2. Haz clic en el nombre de tu clúster y, a continuación, selecciona la pestaña Observabilidad.

  3. Selecciona Control Plane 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 de 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 Google Cloud consola, ve a la página Clústeres de Kubernetes:

    Ve a Clústeres de Kubernetes.

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

  2. Haz clic en el nombre de tu clúster.

  3. En la fila Funciones, busque la opción Cloud Monitoring y haga clic en el icono Editar.

  4. En el cuadro de diálogo Editar monitorización en la nube que aparece, confirma que la opción Habilitar monitorización en la nube esté seleccionada.

  5. En el menú desplegable Componentes, selecciona los componentes del plano de control de los que quieras recoger métricas: Servidor de API, Programador o Gestor de controladores.

  6. Haz clic en Aceptar.

  7. Haz clic en Guardar cambios.

gcloud

Actualiza tu clúster para recoger las métricas emitidas por el servidor de la API de Kubernetes, el programador y el gestor de controladores:

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

Haz los cambios siguientes:

Terraform

Para configurar la recogida de métricas del plano de control de Kubernetes con Terraform, consulta el bloque monitoring_config en el registro de Terraform de 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 "Solicitudes de ingestión de series temporales por minuto" de la API de Cloud Monitoring. Antes de habilitar los paquetes de métricas, consulta el pico de uso reciente de esa cuota. Si tienes muchos clústeres en el mismo proyecto o ya te estás acercando a ese límite de 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 métricas en Cloud Monitoring. Los cargos de Cloud Monitoring por la ingestión de estas métricas se basan en el número de muestras ingeridas.

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

Formato de la 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 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 métrica expuesto por Kubernetes de código abierto.

Exportar datos de Cloud Monitoring

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

Consultar métricas

Cuando consultas métricas del plano de control de Kubernetes, el nombre que usas depende de si utilizas PromQL o funciones basadas en Cloud Monitoring, como MQL o la interfaz basada en menús 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 métrica de PromQL: cuando uses PromQL en las páginas de Cloud Monitoring de la Google Cloud consola o en los campos de PromQL de la API de Cloud Monitoring, usa el nombre de métrica de PromQL.
  • Nombre de la métrica de Cloud Monitoring: cuando uses otras funciones de Cloud Monitoring, utiliza el nombre de la métrica de Cloud Monitoring que aparece en las tablas de abajo. Este nombre debe ir precedido de prometheus.googleapis.com/, que se ha omitido 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 e 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 métricas de Cloud Monitoring de esta tabla deben tener el prefijo prometheus.googleapis.com/. Se ha omitido ese prefijo en las entradas de la tabla.

Nombre de la métrica de PromQL Fase de lanzamiento
Nombre de la métrica de Cloud Monitoring
Tipo, unidad
Recursos monitorizados
Versión de GKE necesaria		 Descripción
Etiquetas
apiserver_current_inflight_requests GA
apiserver_current_inflight_requests/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		Número máximo de solicitudes en curso que se han usado en este servidor de API por tipo de solicitud 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+ 		Concurrencia (número de puestos) ocupada por las solicitudes que se están ejecutando en este momento (fase inicial de una solicitud WATCH o cualquier otra fase) 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) 		Número de solicitudes pendientes 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) 		Número nominal de puestos de ejecución configurados 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) 		Número de solicitudes rechazadas por 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) 		Tiempo que una solicitud ha estado 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 la latencia de respuesta en segundos de cada verbo, valor de prueba, grupo, versión, recurso, subrecurso, ámbito 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 por verbo, valor de prueba, grupo, versión, recurso, ámbito, 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 del tamaño de la respuesta en bytes de cada grupo, versión, verbo, recurso, subrecurso, ámbito 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+ 		Número de objetos almacenados en el momento de la última comprobación, desglosado 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 el nombre y desglosado por cada operación, recurso de API y tipo (validar o admitir).

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 los subpasos de admisión en segundos, desglosado por cada operación, 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 por cada operación, recurso de API y tipo (validar o admitir).

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

Use esta métrica para monitorizar la latencia en el servidor de la API. La duración de la solicitud registrada por esta métrica incluye todas las fases del procesamiento de la solicitud, desde el momento en que se recibe la solicitud hasta que el servidor completa su respuesta al cliente. En concreto, incluye el tiempo dedicado a lo siguiente:

  • La autenticación y la autorización de la solicitud.
  • Llamar a los webhooks de terceros y del sistema asociados a la solicitud.
  • Obtener el objeto solicitado de una caché en memoria (en el caso de las 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 etcd (en el caso de todas las demás solicitudes).
  • Puede usar las etiquetas group, version, resource y subresource para identificar de forma única una solicitud lenta y analizarla en profundidad.
  • Escribir la respuesta al cliente y recibir su respuesta.

Para obtener más información sobre cómo usar esta métrica, consulta Latencia.

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

apiserver_admission_controller_admission_duration_seconds

Esta métrica mide la latencia de los webhooks de admisión integrados, no de los 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 de los webhooks de admisión externos de terceros. La métrica apiserver_admission_webhook_admission_duration_seconds suele ser 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 monitorizar el tráfico de solicitudes en tu servidor de API. También puedes usarlo para determinar los porcentajes de éxito y de error de tus solicitudes. Para obtener más información sobre cómo usar esta métrica, consulta Tasa de tráfico y de errores.

Esta métrica tiene una cardinalidad muy alta. Cuando use esta métrica, debe usar filtros o agrupaciones para identificar las fuentes de errores.

apiserver_storage_objects

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

apiserver_current_inflight_requests

Esta métrica registra el número máximo de solicitudes que se han atendido activamente en la ventana del último segundo. Para obtener más información, consulta Saturación.

La métrica no incluye solicitudes de larga duración, como "watch".

Monitorizar el servidor de la API

Las métricas del servidor de la API pueden proporcionarte información valiosa sobre las principales señales del estado del sistema:

  • Latencia: ¿cuánto tiempo se tarda en atender una solicitud?
  • Tráfico: ¿cuánta demanda está experimentando el sistema?
  • Tasa de errores: ¿con qué frecuencia fallan las solicitudes?
  • Saturación: ¿cuánto se ha llenado el sistema?

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

Latencia

Cuando el servidor de la API está sobrecargado, la latencia de las solicitudes aumenta. 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 forma más específica, puedes agrupar las métricas por la etiqueta verb o resource.

El límite superior sugerido para una llamada de un solo recurso, como GET, POST o PATCH, es de un segundo. El límite superior sugerido para las llamadas LIST con ámbito de espacio de nombres y de clúster es de 30 segundos. Los límites superiores se definen mediante SLOs definidos por la comunidad de Kubernetes de código abierto. Para obtener más información, consulta Detalles de los SLIs y SLOs 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 prevista, investiga las siguientes posibles causas:

  • El plano de control de Kubernetes puede estar sobrecargado. Para comprobarlo, consulte las métricas apiserver_request_total y apiserver_storage_objects.
    • Usa la etiqueta code para determinar si las solicitudes se están procesando correctamente. Para obtener información sobre los posibles valores, 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 provocar retrasos en la programación de los trabajos.

    • 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])))

      También te recomendamos que consultes los percentiles 50, 90, 95 y 99,9.Para ello, puedes modificar el valor 0.99 de esta consulta.

    • Los webhooks externos tienen un límite de tiempo de espera de unos 10 segundos. Puedes definir 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 puede agrupar la métrica apiserver_admission_webhook_admission_duration_seconds name por la etiqueta para diagnosticar posibles problemas con webhooks específicos.

  • Estás mostrando muchos objetos. Es de esperar que la latencia de las llamadas LIST aumente a medida que lo haga el número de objetos de un tipo determinado (el tamaño de la respuesta).

  • Problemas del lado del cliente:

    • Es posible que el cliente no tenga suficientes recursos para recibir respuestas a tiempo. Para comprobarlo, consulta las métricas de uso de CPU del pod del cliente.
    • El cliente tiene una conexión de red lenta. Esto puede ocurrir cuando el cliente se ejecuta en un dispositivo como un teléfono móvil, pero es poco probable que ocurra en clientes que se ejecutan en una red de Compute Engine.
    • El cliente ha salido de forma inesperada, pero la conexión TCP tiene un periodo de tiempo de espera de decenas de segundos. Antes de que se agote el tiempo de espera de la conexión, los recursos del servidor se bloquean, lo que puede aumentar la latencia.

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

Tasa de tráfico y de errores

Para medir el tráfico y el número de solicitudes correctas y fallidas en el servidor de la API, use 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 fallidas, 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 valores 2xx con 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 con 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

Puede medir la saturación de su sistema mediante las métricas apiserver_current_inflight_requests y apiserver_storage_objects .

Si el valor de la métrica apiserver_storage_objects aumenta, puede que haya un problema con un controlador personalizado que crea objetos, pero no los elimina. Puede 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 los ajustes de prioridad y equidad de la API. Estos ajustes influyen en la forma en que se priorizan las solicitudes, por lo que no puedes sacar conclusiones solo a partir de los valores de la métrica. Para obtener más información, consulte Prioridad y equidad de las APIs.

Métricas de Scheduler

En esta sección se proporciona una lista de las métricas del programador e 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 métricas de Cloud Monitoring de esta tabla deben tener el prefijo prometheus.googleapis.com/. Se ha omitido ese prefijo en las entradas de la tabla.

Nombre de la métrica de PromQL Fase de lanzamiento
Nombre de la métrica de Cloud Monitoring
Tipo, unidad
Recursos monitorizados
Versión de GKE necesaria		 Descripción
Etiquetas
kube_pod_resource_limit GA
kube_pod_resource_limit/gauge
Gauge, Double, 1
prometheus_target
1.31.1-gke.1621000+ 		Límite de recursos para las cargas de trabajo del clúster, desglosado por pod. Aquí se muestra el uso de recursos que el programador y kubelet esperan por pod para el recurso, junto con la unidad del recurso, si la hay.

namespace
node
pod
priority
resource
scheduler
unit
kube_pod_resource_request GA
kube_pod_resource_request/gauge
Gauge, Double, 1
prometheus_target
1.31.1-gke.1621000+ 		Recursos solicitados por las cargas de trabajo del clúster, desglosados por pod. Aquí se muestra el uso de recursos que el programador y kubelet esperan por pod para el recurso, junto con la unidad del recurso, si la hay.

namespace
node
pod
priority
resource
scheduler
unit
scheduler_pending_pods GA
scheduler_pending_pods/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		Número de pods pendientes, por tipo de cola. "active" significa el número de pods en activeQ; "backoff" significa el número de pods en backoffQ; "unschedulable" significa el número de pods en unschedulablePods.

queue
scheduler_pod_scheduling_duration_seconds OBSOLETO
scheduler_pod_scheduling_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
De 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 ha quitado en la versión 1.30 y se ha sustituido por scheduler_pod_scheduling_sli_duration_seconds]. Latencia de extremo a extremo de un pod programado, 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 de extremo a extremo de un pod que se va a programar, desde el momento en que el pod entra en la cola de programación. 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+ 		Número total de intentos de expropiación en el clúster hasta ahora
scheduler_preemption_victims GA
scheduler_preemption_victims/histogram
Cumulative, Distribution, 1
prometheus_target
1.22.13+ 		Número de víctimas de la expropiación seleccionadas
scheduler_scheduling_attempt_duration_seconds GA
scheduler_scheduling_attempt_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.23.6+ 		Latencia del intento de programación en segundos (algoritmo de programación + enlace).

profile
result
scheduler_schedule_attempts_total GA
scheduler_schedule_attempts_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		Número de intentos de programar pods, por resultado. "unschedulable" (no se puede programar) significa que no se ha podido programar un pod, mientras que "error" significa que se ha producido un problema interno en el 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 monitorizar la carga de tu programador. Si los valores de esta métrica aumentan, puede que haya problemas con los recursos. El programador tiene tres colas y esta métrica indica el número de solicitudes pendientes por cola. Se admiten las siguientes colas:

  • active cola
    • El conjunto de pods que el programador está intentando programar. El pod con la prioridad más alta está al principio de la cola.
  • backoff cola
    • El conjunto de pods no se pudo programar la última vez que lo intentó el programador, pero podría programarse la próxima vez.
    • Los pods de esta cola deben esperar un periodo de retardo (un máximo de 10 segundos), tras el cual se vuelven a colocar en la cola active para intentar programarlos de nuevo. Para obtener más información sobre la gestión de la cola backoff, consulta la solicitud de implementación problema 75417 de Kubernetes.

  • unschedulable serie

    • El conjunto de pods que el programador ha intentado programar, pero que se ha determinado que no se pueden programar. La colocación en esta cola puede indicar problemas de preparación o de compatibilidad con tus nodos o con la configuración de tus selectores de nodos.

      Cuando las restricciones de recursos impiden que se programen pods, estos no están sujetos a la gestión de retiros. En su lugar, cuando un clúster está lleno, no se pueden programar pods nuevos y se colocan en la cola unscheduled.

    • La presencia de pods no programados puede indicar que no tienes suficientes recursos 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 ha cambiado nada en el clúster que haga que los pods se puedan programar.

    • Afinidades: definen reglas sobre cómo se asignan los pods a los nodos. El uso de reglas de afinidad o antiafinidad puede ser la causa de un aumento de los pods no programados.

    • Algunos eventos, como la adición o actualización de PVC o de servicios, 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 el problema 81214 de Kubernetes.

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

scheduler_scheduling_attempt_duration_seconds

Esta métrica mide la duración de un solo intento de programación dentro del propio programador y se desglosa por resultado: programado, no programable o error. La duración va desde el momento en que el programador recoge un pod hasta que el programador localiza un nodo y coloca el pod en el nodo, determina que el pod no se puede programar o se produce un error. La duración de la programación incluye el tiempo del proceso de programación y el tiempo de vinculación. El enlace es el proceso por 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 registra el tiempo que el pod pasa en el control de admisión o en la validación.

Para obtener más información sobre la programación, consulta Programar un pod.

scheduler_schedule_attempts_total

Esta métrica mide el número de intentos de programación. Cada intento de programar un pod aumenta el valor. Puede usar esta métrica para determinar si el programador está disponible: si el valor aumenta, significa que el programador está operativo. Puedes usar la etiqueta result para determinar si se ha completado correctamente. Los pods pueden ser scheduled o unschedulable.

Esta métrica está muy relacionada con la métrica scheduler_pending_pods: cuando hay muchos pods pendientes, es de esperar que haya muchos intentos de programar los pods. Para obtener más información, consulta Problemas con los recursos.

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

scheduler_preemption_attempts_total y scheduler_preemptions_victims

Puedes usar métricas de preferencia para determinar si necesitas añadir 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 quitando uno o varios pods en ejecución de un nodo. La métrica scheduler_preemption_attempts_total registra el número de veces que el programador ha intentado expropiar pods.

La métrica scheduler_preemptions_victims cuenta los pods seleccionados para la expropiación.

El número de intentos de apropiación está muy relacionado 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 habrá intentos de expropiación, pero puede haber intentos de programación que fallen.

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

Monitorizar el programador

Las métricas del programador pueden proporcionarte información valiosa sobre el rendimiento de tu programador:

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

Latencia del programador

La tarea del programador es asegurarse de que tus pods se ejecuten, por lo que te interesa saber cuándo se bloquea o se ejecuta lentamente.

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

  • Si el programador funciona con lentitud, investiga las siguientes posibles causas:

    • El número de pods pendientes aumenta. Usa la métrica scheduler_pending_pods para monitorizar el número de pods pendientes. La siguiente consulta PromQL devuelve el número 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 monitorizar 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 obtiene 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 con los 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, comprueba el valor de scheduler_preemption_victims con la siguiente consulta de PromQL:

scheduler_preemption_victims_sum{cluster="CLUSTER_NAME"}

El número de intentos de expropiación y el número de víctimas de expropiación aumentan cuando hay pods de mayor prioridad que programar. Las métricas de preferencia no indican si se han programado los pods de alta prioridad que han activado las preferencias, por lo que, cuando vea aumentos en el valor de las métricas de preferencia, también puede monitorizar el valor de la métrica scheduler_pending_pods. Si el número de pods pendientes también aumenta, es posible que no tengas suficientes recursos para gestionar los pods de mayor prioridad. En ese caso, tendrás que aumentar los recursos disponibles, crear pods con reclamaciones de recursos reducidas o cambiar el selector de nodos.

  • Si el número de víctimas de la expropiación no aumenta, significa que no quedan pods de baja prioridad que se puedan eliminar. En este caso, te recomendamos que añadas más nodos para que se puedan asignar los nuevos pods.

  • Si el número de víctimas de la expropiación aumenta, significa que hay pods de mayor prioridad esperando a programarse, por lo que el programador está expropiando algunos de los pods en ejecución. Las métricas de preferencia no indican si los pods de mayor prioridad se han programado 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 tengas que añadir más nodos.

Puedes esperar picos temporales en los valores de la métrica scheduler_pending_pods cuando se vayan a programar cargas de trabajo en tu clúster, por ejemplo, durante eventos como actualizaciones o escalados. Si tienes suficientes recursos en tu clúster, estos picos son temporales. Si el número de pods pendientes no disminuye, haz lo siguiente:

  • Comprueba que los nodos no estén acordonados, ya que los nodos acordonados no aceptan pods nuevos.
  • Comprueba las siguientes directivas de programación, que pueden estar mal configuradas y podrían hacer que un pod no se pueda programar:
    • Afinidad y selector de nodos.
    • Tolerancias e intolerancias.
    • Restricciones de distribución de topología de pods.

Si no se pueden programar pods debido a que no hay suficientes recursos, considera liberar algunos de los nodos que ya tienes o aumentar el número de nodos.

Métricas de Controller Manager

Cuando las métricas del gestor 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 métricas de Cloud Monitoring de esta tabla deben tener el prefijo prometheus.googleapis.com/. Se ha omitido ese prefijo en las entradas de la tabla.

Nombre de la métrica de PromQL Fase de lanzamiento
Nombre de la métrica de Cloud Monitoring
Tipo, unidad
Recursos monitorizados
Versión de GKE necesaria		 Descripción
Etiquetas
node_collector_evictions_total GA
node_collector_evictions_total/counter
Cumulative, Double, 1
prometheus_target
1.24+ 		Número de desalojos de nodos que se han producido desde que se inició la instancia actual de NodeController.

zone