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 de vLLM.

Luego, el balanceador de cargas puede usar estos datos con el balanceo de cargas basado en la utilización para equilibrar las cargas de trabajo de manera más eficiente. Por ejemplo, puedes usar esta función para supervisar las regiones con un uso de carga de trabajo más pesado y, luego, permitir que el balanceador de cargas redireccione el tráfico hacia la región con los recursos más disponibles. En el ejemplo de vLLM, una métrica que podría ser útil para hacer un seguimiento de la utilización 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 la carga tu puerta de enlace. La ruta de acceso del extremo predeterminada 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 tener más de 64 caracteres. Para obtener la lista completa de restricciones, consulta los detalles sobre el campo backends[].customMetrics[].name en la referencia de la API para 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, donde 1 representa el 100% de uso.

  • Los nombres de las etiquetas en los selectores de etiquetas de Pod no deben contener caracteres especiales. Solo se admiten letras de la A a la Z (mayúsculas o minú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 con 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 para la API de Gateway: Solo puedes usar UBB con métricas personalizadas con los servicios que expones a través de la API de Gateway. GKE usa el controlador de Gateway de GKE para interactuar con la API de Gateway. Las APIs de Service y de Ingress no admiten UBB con métricas personalizadas. Las métricas personalizadas deben originarse en los Pods que son miembros de los Services.
  • 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 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: Es el nombre del objeto AutoscalingMetric.
    • NAMESPACE: Es el espacio de nombres en el que se encuentran los Pods.
    • APP_LABEL_NAME y APP_LABEL_VALUE: Son el nombre y el valor de la etiqueta que coinciden con los Pods que emiten la métrica.
    • METRIC_PORT: Es el número de puerto.
    • METRIC_PATH: Es 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: Es 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: Es 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 agregas el recurso personalizado, la métrica se envía 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 un 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 nomenclatura diferente. Cuando se registran las métricas para el balanceo de cargas, el agente de métricas de GKE les agrega internamente el prefijo gke.named_metrics. para cumplir con 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 información, consulta Configura el balanceador de cargas para que use métricas personalizadas.

Para obtener más información sobre cómo trabajar con el balanceador de cargas, consulta Configura el balanceo de cargas basado en la utilización 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:

¿Qué sigue?