Métriques personnalisées natives sur GKE : un autoscaling intelligent au-delà du CPU et de la mémoire

L'autoscaling sur Kubernetes repose généralement sur le Horizontal Pod Autoscaler (HPA). Par défaut, le HPA met à l'échelle les workloads en fonction de l'utilisation des ressources, comme le CPU ou la mémoire. Cette approche convient à beaucoup de workloads, mais elle ne reflète pas toujours la demande réelle exercée sur une application.

Quelques exemples :

• Une API web peut subir un trafic important sans que le CPU soit fortement sollicité.
• Un service de traitement de file d'attente peut nécessiter davantage de workers lorsque le backlog grossit.
• Les workloads d'inférence IA dépendent souvent davantage du GPU que du CPU.
• Les services de streaming peuvent nécessiter un scaling basé sur le nombre de requêtes par seconde.

Ces scénarios exigent un scaling fondé sur des métriques applicatives, et non sur des métriques d'infrastructure.

Kubernetes prend en charge l'autoscaling sur métriques personnalisées, mais sa mise en œuvre exigeait historiquement plusieurs composants supplémentaires :

• Adaptateurs Prometheus — un déploiement distinct qui fait le lien entre les métriques Prometheus et l'API metrics de Kubernetes
• Pipelines de métriques personnalisés — couches d'ingestion, de stockage et de requêtage intercalées entre l'application et le HPA
• Configuration IAM et compte de service complexe — particulièrement dans les environnements managés comme GKE

Source : Gemini Nano Banana Pro

La charge opérationnelle de ces composants était lourde : suivi de la compatibilité des adaptateurs avec les versions de Kubernetes, débogage de pipelines de métriques multi-sauts, gestion de la latence introduite par les couches d'infrastructure. Cette friction a freiné l'adoption et poussé de nombreuses équipes à revenir au scaling basé sur le CPU.

GKE propose désormais une intégration native pour exposer les métriques personnalisées et simplifier la façon dont les applications les partagent avec le système d'autoscaling. Plutôt que de transiter par des adaptateurs externes et des systèmes de monitoring, les métriques personnalisées sont collectées directement depuis les pods et transmises au HPA.

Le système d'autoscaling peut ainsi réagir au comportement réel de l'application — débit de requêtes, utilisation des ressources, etc. L'intégration des métriques applicatives aux stratégies de scaling s'en trouve grandement facilitée.

Source : Gemini Nano Banana Pro

Cette nouvelle capacité repose sur une ressource appelée AutoscalingMetric.

Cette ressource définit :

• Quels pods exposent les métriques (via des sélecteurs de labels)
• Où se trouve l'endpoint des métriques (port et chemin)
• Quelle métrique précise doit être collectée
• Comment cette métrique doit être exportée vers le système d'autoscaling

Une fois définies, ces métriques sont collectées par GKE et mises à disposition de composants tels que le load balancer ou l'autoscaler.

Principaux prérequis :

• Les métriques doivent être disponibles via un endpoint HTTP
• Le format doit respecter les standards Prometheus
• Seules les métriques de type gauge sont prises en charge.
• Maximum de 20 métriques uniques exposables par cluster.

Gauge et autres types de métriques : une gauge représente une valeur qui peut augmenter ou diminuer à tout moment (ex. : longueur actuelle de la file d'attente = 45). Les counters ne font qu'augmenter (ex. : total des requêtes traitées = 10 432) et ne conviennent pas comme cibles directes d'autoscaling. Si votre application expose actuellement des counters, vous devrez en dériver une gauge (par exemple un taux de requêtes calculé) avant de l'utiliser avec cette fonctionnalité.

Une fois la métrique enregistrée, GKE en lit la valeur en continu et l'injecte dans la logique de scaling.

Voici un exemple complet et autonome.

Scénario : un service worker en arrière-plan traite des jobs issus d'une file d'attente. Nous voulons ajuster le nombre de pods worker en fonction de la longueur actuelle de la file — et non de l'utilisation du CPU.

Étape 1 : exposer la métrique depuis l'application

Déployez votre application en exposant une métrique de type gauge au format Prometheus sur son endpoint /metrics :

# HELP job_queue_length Current number of jobs waiting in the queue
# TYPE job_queue_length gauge
job_queue_length 45

Supposons que les métriques soient disponibles à l'adresse http://worker-service:9090/metrics.

Étape 2 : créer une ressource AutoscalingMetric

Définissez une ressource AutoscalingMetric qui indique à GKE où trouver la métrique et comment l'exporter :

apiVersion: autoscaling.gke.io/v1beta1
kind: AutoscalingMetric
metadata:
  name: worker-queue-metric
  namespace: default
spec:
  selector:
    matchLabels:
      app: job-worker #The label name and value matching the Pods
  endpoints:
  - port: 9090 #The metrics port number
    path: /metrics #The path to the metric
    metrics:
    - gauge:
      name: job_queue_length #The name of the metric that you are exposing.
      prometheusMetricName: job_queue_length #optional: The Prometheus metric name as exposed by the Pod.

Une fois appliquée, la métrique est disponible pour le système d'autoscaling.

Créons à présent un HPA qui exploite cette métrique personnalisée.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: worker-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: job-worker
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: autoscaling.gke.io|worker-queue-metric|queue_utilization
      target:
        type: AverageValue
        averageValue: 20

Concrètement :

• Si la taille moyenne de la file dépasse 20 jobs par pod, le système monte en charge.
• Si la file se réduit, il descend en charge.

Cette fonctionnalité offre plusieurs atouts majeurs.

• Un scaling piloté par l'application : les décisions de scaling reflètent la demande réelle, et non des indicateurs d'infrastructure indirects.
• Moins de complexité opérationnelle : finis les adaptateurs externes et les pipelines de métriques alambiqués.
• De meilleures performances : les applications passent à l'échelle avec plus de précision et réagissent plus vite aux pics de charge.
• Une utilisation des ressources optimisée : les coûts d'infrastructure baissent, car le scaling s'aligne sur la demande réelle.
• Des stratégies d'autoscaling flexibles : les équipes peuvent bâtir des politiques autour de n'importe quelle métrique de type gauge exposée par leur application : profondeur de file d'attente, sessions actives, rendus en attente, etc.