Expón métricas personalizadas para los balanceadores de cargas

En este documento, se describe cómo enviar una o más métricas desde un Pod o una carga de trabajo a tu balanceador de cargas.

Estas métricas provienen del servicio o la aplicación que estás ejecutando. Por ejemplo, consulta las métricas expuestas por el motor vLLM.

Luego, el balanceador de cargas puede usar estos datos con el balanceo de cargas basado en el uso para balancear las cargas de trabajo de manera más eficiente. Por ejemplo, puedes usar esta función para supervisar las regiones con un uso más intenso de la carga de trabajo y, luego, permitir que el balanceador de cargas redireccione el tráfico hacia la región con más recursos disponibles. En el ejemplo de vLLM, una métrica que podría ser útil para hacer un seguimiento del uso es vllm:gpu_cache_usage_perc.

Requisitos

Los requisitos para los Pods son los siguientes:

Los requisitos para las métricas son los siguientes:

  • Se debe poder acceder a las métricas en un extremo HTTP en los Pods que balancea tu puerta de enlace. La ruta de acceso predeterminada del extremo es /metrics.
  • Las métricas deben tener el formato según el estándar de Prometheus.
  • Los balanceadores de cargas tienen restricciones en los nombres de las métricas. Por ejemplo, el nombre no puede exceder los 64 caracteres. Para obtener la lista completa de restricciones, consulta los detalles sobre el campo backends[].customMetrics[].name en la referencia de la API de BackendService.

    Si la métrica de tu servicio no cumple con estas restricciones, puedes cambiarle el nombre con el campo exportName.

  • Solo se admiten métricas de indicador entre 0 y 1, en las que 1 representa un uso del 100%.

  • Los nombres de las etiquetas en los selectores de etiquetas de Pods no deben contener caracteres especiales. Solo se admiten letras de la a a la z (minúsculas o mayúsculas), números, guiones y guiones bajos.

  • Se puede exponer un máximo de 20 métricas únicas por clúster. Otros servicios tienen sus propios límites. Por ejemplo, consulta los límites y requisitos de los balanceadores de cargas. Ten en cuenta que un clúster puede usar más de un balanceador de cargas.

Balanceo basado en el uso (UBB) de GKE basado en métricas personalizadas

Puedes usar el balanceo basado en el uso (UBB) de GKE para permitir que el balanceador de cargas distribuya el tráfico según el uso de tus Pods de backend. En lugar de depender de una métrica genérica como la CPU, puedes configurar UBB para que use métricas personalizadas que sean más relevantes para el rendimiento de tu aplicación.

Cuando usas UBB con métricas personalizadas en GKE, se aplican las siguientes limitaciones:

  • Solo API de Gateway: Solo puedes usar UBB con métricas personalizadas con los servicios que expones con la API de Gateway. GKE usa el controlador de Gateway de GKE para interactuar con la API de Gateway. Las APIs de Service y Ingress no admiten UBB con métricas personalizadas. Las métricas personalizadas deben provenir de los Pods que son miembros de los servicios.
  • Sin Cloud Service Mesh: No puedes usar UBB con métricas personalizadas con Cloud Service Mesh.
  • Balanceadores de cargas no compatibles: No puedes usar UBB con métricas personalizadas con balanceadores de cargas de red de transferencia externos ni balanceadores de cargas de red de proxy externos.

Expón métricas para el balanceo de cargas

  1. Elige una métrica para exponer. Puedes elegir cualquier métrica que exponga tu servidor y que también cumpla con los requisitos que se indican en la sección anterior. En este ejemplo, se usa una métrica personalizada llamada queue_depth_util.

  2. Agrega el siguiente recurso personalizado y reemplaza los detalles que son específicos de tu métrica y Pod:

    apiVersion: autoscaling.gke.io/v1beta1
    kind: AutoscalingMetric
    metadata:
      name: NAME
      namespace:NAMESPACE
    spec:
      metrics:
      - pod:
          selector:
            matchLabels:
              APP_LABEL_NAME: APP_LABEL_VALUE
          containers:
          - endpoint:
              port: METRIC_PORT
              path: METRIC_PATH
            metrics:
            - gauge:
              name: METRIC
              prometheusMetricName: METRIC_PROMETHEUS_NAME
              loadBalancing:
                enabled: true
    

    Reemplaza lo siguiente para que coincida con tu carga de trabajo:

    • NAME: El nombre del objeto AutoscalingMetric.
    • NAMESPACE: El espacio de nombres en el que se encuentran los Pods.
    • APP_LABEL_NAME y APP_LABEL_VALUE: El nombre y el valor de la etiqueta que coinciden con los Pods que emiten la métrica.
    • METRIC_PORT: El número de puerto.
    • METRIC_PATH: La ruta de acceso a la métrica. Verifica la ruta de acceso que usa tu servicio o aplicación. Esta ruta de acceso suele ser /metrics.
    • METRIC: El nombre de la métrica que expones. El nombre debe coincidir con la expresión regular ^[a-z]([a-z0-9_-]*[a-z0-9])? y tener una longitud de no más de 63 caracteres. Esto significa que el primer carácter debe ser una letra minúscula y todos los caracteres siguientes deben ser guiones, guiones bajos, letras minúsculas o dígitos, excepto el último carácter, que debe ser una letra o un dígito.
    • Opcional: METRIC_PROMETHEUS_NAME: El nombre de la métrica de Prometheus tal como la expone el Pod. Puedes usar este campo para cambiar el nombre de la métrica, por ejemplo, porque el nombre de la métrica que expone el Pod no cumple con las restricciones de nombre establecidas por el balanceador de cargas.

      Para obtener la lista completa de restricciones, consulta los detalles sobre el campo backends[].customMetrics[].name en la referencia de la API de BackendService.

  3. Aplica el manifiesto con el siguiente comando:

    kubectl apply -f FILE_NAME.yaml
    

    Reemplaza FILE_NAME por el nombre del archivo YAML.

    Cuando agregues el recurso personalizado, la métrica se enviará a la API de ajuste de escala automático. La métrica se lee cada pocos segundos y se envía al balanceador de cargas.

  4. Para usar este indicador con fines de balanceo de cargas, proporciona una GCPBackendPolicy. Por ejemplo:

    kind: GCPBackendPolicy
    apiVersion: networking.gke.io/v1
    metadata:
      name: my-backend-policy
    spec:
      targetRef:
        group: ""
        kind: Service
        name: store-v1
      default:
        balancingMode: CUSTOM_METRICS
        customMetrics:
        -   name: gke.named_metrics.queue_depth_util
            dryRun: false
    

Ten en cuenta que las métricas que informa Prometheus siguen un estándar de nombres diferente. Cuando se informan las métricas para el balanceo de cargas, el agente de métricas de GKE las agregará internamente con el prefijo gke.named_metrics. para seguir el requisito de la API de BackendService.

Para exponer una segunda métrica, sigue los mismos pasos para crear otro recurso personalizado.

Ahora que expusiste las métricas al balanceador de cargas, puedes configurarlo para que las use. Para obtener más detalles, consulta Configura el balanceador de cargas para usar métricas personalizadas.

Si deseas obtener más información para trabajar con el balanceador de cargas, consulta Configura el balanceo de cargas basado en el uso para los servicios de GKE.

Soluciona problemas de las métricas que se exponen al balanceador de cargas

Para verificar que las métricas se expongan correctamente al balanceador de cargas, puedes hacer lo siguiente:

  • Verifica los registros en el agente de métricas de GKE. Si se produjo un error cuando se intentó exponer las métricas, es posible que los registros hayan indicado que hay un error. Si deseas obtener más información para buscar errores, consulta Soluciona problemas de métricas del sistema.
  • Puedes usar el balanceador de cargas en el modo de ejecución de prueba para ver todas las métricas que recibe. Para obtener más información sobre cómo probar las métricas con la marca dryRun, consulta Configura el balanceador de cargas para usar métricas personalizadas.

¿Qué sigue?