Exposer des métriques personnalisées pour les équilibreurs de charge

Ce document explique comment envoyer une ou plusieurs métriques d'un pod ou d'une charge de travail à votre équilibreur de charge.

Ces métriques proviennent du service ou de l'application que vous exécutez. Par exemple, consultez les métriques exposées par le moteur vLLM.

L'équilibreur de charge peut ensuite utiliser ces données avec l'équilibrage de charge basé sur l'utilisation pour équilibrer les charges de travail plus efficacement. Par exemple, vous pouvez utiliser cette fonctionnalité pour surveiller les régions où l'utilisation de la charge de travail est plus importante, puis autoriser l'équilibreur de charge à rediriger le trafic vers la région disposant de plus de ressources disponibles. Dans l'exemple vLLM, une métrique qui pourrait être utile pour suivre l'utilisation est vllm:gpu_cache_usage_perc.

Conditions requises

Les conditions requises pour les pods sont les suivantes :

Les conditions requises pour les métriques sont les suivantes.

  • Les métriques doivent être accessibles sur un point de terminaison HTTP sous les pods qui sont équilibrés par votre passerelle. Le chemin d'accès au point de terminaison par défaut est /metrics.
  • Les métriques doivent être mises en forme conformément à la norme Prometheus.

  • Les équilibreurs de charge sont soumis à des restrictions concernant les noms de métriques. Par exemple, le nom ne peut pas dépasser 64 caractères. Pour obtenir la liste complète des restrictions, consultez les détails concernant le champ backends[].customMetrics[].name dans la documentation de référence de l'API pour BackendService.

    Si la métrique de votre service ne respecte pas ces restrictions, vous pouvez la renommer à l'aide du champ exportName.

  • Seules les métriques de jauge comprises entre 0 et 1 sont acceptées, 1 représentant une utilisation de 100%.

  • Les noms de libellés dans les sélecteurs de libellés de pods ne doivent pas contenir de caractères spéciaux. Seuls les caractères a à z (minuscules ou majuscules), les chiffres, les traits d'union et les traits de soulignement sont acceptés.

  • Vous pouvez exposer au maximum 20 métriques uniques par cluster. D'autres services ont leurs propres limites. Par exemple, consultez les limites et les exigences concernant les équilibreurs de charge. Notez qu'un cluster peut utiliser plusieurs équilibreurs de charge.

Équilibrage basé sur l'utilisation GKE basé sur des métriques personnalisées

Vous pouvez utiliser l'équilibrage basé sur l'utilisation GKE pour permettre à l'équilibreur de charge de distribuer le trafic en fonction de l'utilisation de vos pods de backend. Au lieu de vous appuyer sur une métrique générique comme le processeur, vous pouvez configurer l'équilibrage basé sur l'utilisation pour qu'il utilise des métriques personnalisées plus pertinentes pour les performances de votre application.

Lorsque vous utilisez l'équilibrage basé sur l'utilisation avec des métriques personnalisées dans GKE, les limites suivantes s'appliquent :

  • API Gateway uniquement : vous ne pouvez utiliser l'équilibrage basé sur l'utilisation avec des métriques personnalisées qu'avec les services que vous exposez à l'aide de l'API Gateway. GKE utilise le contrôleur GKE Gateway pour interagir avec l'API Gateway. Les API Service et Ingress ne sont pas compatibles avec l'équilibrage basé sur l'utilisation avec des métriques personnalisées. Les métriques personnalisées doivent provenir des pods membres des services.
  • Pas de Cloud Service Mesh : vous ne pouvez pas utiliser l'équilibrage basé sur l'utilisation avec des métriques personnalisées avec Cloud Service Mesh.
  • Équilibreurs de charge non compatibles : vous ne pouvez pas utiliser l'équilibrage basé sur l'utilisation avec des métriques personnalisées avec les équilibreurs de charge réseau passthrough externes et l'équilibreur de charge réseau proxy externe.

Exposer des métriques pour l'équilibrage de charge

  1. Choisissez une métrique à exposer. Vous pouvez choisir n'importe quelle métrique exposée par votre serveur et qui répond également aux exigences listées dans la section précédente. Cet exemple utilise une métrique personnalisée nommée queue_depth_util.

  2. Ajoutez la ressource personnalisée suivante en remplaçant les détails spécifiques à votre métrique et à votre 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

    Remplacez les éléments suivants pour qu'ils correspondent à votre charge de travail :

    • NAME : nom de l'objet AutoscalingMetric.
    • NAMESPACE : espace de noms dans lequel se trouvent les pods.
    • APP_LABEL_NAME et APP_LABEL_VALUE : nom et valeur du libellé correspondant aux pods qui émettent la métrique.
    • METRIC_PORT : numéro de port.
    • METRIC_PATH : chemin d'accès à la métrique. Vérifiez le chemin d'accès utilisé par votre service ou application. Il s'agit souvent de /metrics.
    • METRIC: nom de la métrique que vous exposez. Le nom doit correspondre à l'expression régulière ^[a-z]([a-z0-9_-]*[a-z0-9])? et ne pas dépasser 63 caractères. Cela signifie que le premier caractère doit être une lettre minuscule, et que tous les caractères suivants doivent être des traits d'union, des traits de soulignement, des lettres minuscules ou des chiffres, à l'exception du dernier caractère, qui doit être une lettre ou un chiffre.

    • Facultatif : METRIC_PROMETHEUS_NAME : nom de la métrique Prometheus tel qu'exposé par le pod. Vous pouvez utiliser ce champ pour renommer la métrique, par exemple, car le nom de la métrique exposée par le pod ne respecte pas les restrictions de nom définies par l'équilibreur de charge.

      Pour obtenir la liste complète des restrictions, consultez les détails concernant le champ backends[].customMetrics[].name dans la documentation de référence de l'API pour BackendService.

  3. Appliquez le fichier manifeste à l'aide de la commande suivante :

    kubectl apply -f FILE_NAME.yaml

    Remplacez FILE_NAME par le nom du fichier YAML.

    Une fois la ressource personnalisée ajoutée, la métrique est envoyée à l'API d'autoscaling. La métrique est lue toutes les quelques secondes et envoyée à l'équilibreur de charge.

  4. Pour utiliser ce signal à des fins d'équilibrage de charge, fournissez une GCPBackendPolicy. Exemple :

    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

Notez que les métriques signalées par Prometheus suivent une norme de nommage différente. Lorsque les métriques sont signalées pour l'équilibrage de charge, l'agent de métriques GKE les préfixe en interne avec gke.named_metrics. pour respecter l'exigence de l'API BackendService.

Pour exposer une deuxième métrique, suivez les mêmes étapes pour créer une autre ressource personnalisée.

Maintenant que vous avez exposé les métriques à l'équilibreur de charge, vous pouvez le configurer pour qu'il les utilise. Pour en savoir plus, consultez Configurer l'équilibreur de charge pour qu'il utilise des métriques personnalisées.

Pour en savoir plus sur l'utilisation de l'équilibreur de charge, consultez Configurer l'équilibrage de charge basé sur l'utilisation pour les services GKE.

Résoudre les problèmes liés aux métriques exposées à l'équilibreur de charge

Pour vérifier que les métriques sont correctement exposées à l'équilibreur de charge, vous pouvez procéder comme suit :

Étape suivante