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, vllm:gpu_cache_usage_perc est une métrique qui peut être utile pour suivre l'utilisation.

Conditions requises

Voici les exigences concernant les pods :

Voici les exigences concernant les métriques :

  • Les métriques doivent être accessibles sur un point de terminaison HTTP sous les pods dont l'équilibrage de charge est assuré par votre passerelle. Le chemin d'accès au point de terminaison par défaut est /metrics.
  • Les métriques doivent être formatées 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 du 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 pod 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 jusqu'à 20 métriques uniques par cluster. D'autres services ont leurs propres limites. Par exemple, consultez les limites et exigences pour les équilibreurs de charge. Notez qu'un cluster peut utiliser plusieurs équilibreurs de charge.

Équilibrage de charge basé sur l'utilisation (UBB) de GKE basé sur des métriques personnalisées

Vous pouvez utiliser l'équilibrage basé sur l'utilisation (UBB) de 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 UBB pour qu'il utilise des métriques personnalisées plus pertinentes pour les performances de votre application.

Lorsque vous utilisez UBB avec des métriques personnalisées dans GKE, les limites suivantes s'appliquent :

  • API Gateway uniquement : vous ne pouvez utiliser UBB 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 UBB 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'UBB avec des métriques personnalisées avec Cloud Service Mesh.
  • Équilibreurs de charge non compatibles : vous ne pouvez pas utiliser UBB avec des métriques personnalisées avec les équilibreurs de charge réseau passthrough externes et les équilibreurs de charge réseau proxy externes.

Exposer les 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 de l'étiquette 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 votre application. Ce chemin d'accès est souvent /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 doit pas dépasser 63 caractères. Cela signifie que le premier caractère doit être une lettre minuscule, et tous les caractères suivants doivent être des tirets, 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 telle qu'exposée par le pod. Vous pouvez utiliser ce champ pour renommer la métrique, par exemple parce que 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 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 un 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 dénomination 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 les exigences 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 configurer l'équilibreur de charge pour qu'il les utilise. Pour en savoir plus, consultez Configurer l'équilibreur de charge pour utiliser 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 :

Étapes suivantes