Autoscaling più intelligente su GKE: oltre CPU e memoria con le metriche personalizzate

L'autoscaling in Kubernetes si affida tipicamente all'Horizontal Pod Autoscaler (HPA). Per impostazione predefinita, l'HPA scala i workloads in base all'utilizzo delle risorse, ad esempio CPU o memoria. Si tratta di un approccio efficace per molti workloads, ma che non sempre rispecchia la domanda reale a cui è sottoposta un'applicazione.

Qualche esempio:

• Una web API può ricevere un volume elevato di richieste senza che la CPU sia particolarmente sollecitata.
• Un servizio che elabora code può aver bisogno di più worker quando il backlog cresce.
• I workloads di inferenza AI possono dipendere più dall'utilizzo della GPU che da quello della CPU.
• I servizi di streaming possono richiedere uno scaling basato sulle richieste al secondo.

In tutti questi scenari serve uno scaling basato su metriche applicative, non su metriche infrastrutturali.

Kubernetes supporta l'autoscaling basato su metriche personalizzate, ma storicamente la sua implementazione richiedeva componenti aggiuntivi come:

• Adattatori Prometheus — un deployment a sé stante che fa da ponte tra le metriche Prometheus e le metric API di Kubernetes
• Pipeline di metriche personalizzate — livelli di ingestion, storage e query interposti tra l'applicazione e l'HPA
• Configurazioni complesse di IAM e service account — soprattutto in ambienti gestiti come GKE

Fonte: Gemini Nano Banana Pro

L'onere operativo di questi componenti era tutt'altro che trascurabile: i team dovevano garantire la compatibilità degli adattatori tra le diverse versioni di Kubernetes, fare il debug di pipeline di metriche multi-hop e fare i conti con la latenza introdotta dai livelli infrastrutturali. Un attrito che ha rallentato l'adozione e ha spinto molti team a tornare allo scaling basato sulla CPU.

GKE offre ora un'integrazione nativa per esporre le metriche personalizzate, semplificando il modo in cui le applicazioni le condividono con il sistema di autoscaling. Anziché passare per adattatori esterni e sistemi di monitoraggio, le metriche personalizzate vengono raccolte direttamente dai pod e inoltrate all'HPA.

Il sistema di autoscaling può così reagire al comportamento reale dell'applicazione — ad esempio al throughput delle richieste o all'utilizzo delle risorse — semplificando in modo significativo l'integrazione delle metriche applicative nelle strategie di scaling.

Fonte: Gemini Nano Banana Pro

La nuova funzionalità si basa su una risorsa chiamata AutoscalingMetric.

Questa risorsa definisce:

• Quali pod espongono le metriche (tramite label selector)
• Dove si trova l'endpoint delle metriche (porta e path)
• Quale metrica specifica deve essere raccolta
• Come la metrica deve essere esportata verso il sistema di autoscaling

Una volta definita la risorsa, GKE raccoglie le metriche e le mette a disposizione di componenti come il load balancer o l'autoscaler.

I requisiti principali sono:

• Le metriche devono essere disponibili tramite un endpoint HTTP
• Il formato deve essere conforme agli standard Prometheus
• Sono supportate solo metriche di tipo gauge.
• È possibile esporre al massimo 20 metriche uniche per cluster.

Gauge e altri tipi di metrica: una gauge rappresenta un valore che può aumentare o diminuire in qualsiasi momento (ad esempio, lunghezza attuale della coda = 45). I counter, invece, possono solo crescere (ad esempio, totale richieste elaborate = 10.432) e non sono adatti come target diretto per l'autoscaling. Se la sua applicazione espone counter, dovrà ricavarne una gauge (per esempio, un tasso di richieste calcolato) prima di poter utilizzare questa funzionalità.

Una volta registrata, GKE legge la metrica in modo continuativo e ne fornisce il valore alla logica di scaling.

Vediamo un esempio completo e autoconsistente.

Scenario: un servizio worker in background elabora job da una coda. Vogliamo scalare il numero di pod worker in base alla lunghezza attuale della coda, non all'utilizzo della CPU.

Passo 1: esporre la metrica dall'applicazione

Effettui il deploy della sua applicazione, che espone una metrica gauge in formato Prometheus sull'endpoint /metrics:

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

Supponiamo che le metriche siano disponibili all'indirizzo http://worker-service:9090/metrics

Passo 2: creare una risorsa AutoscalingMetric

Definisca una risorsa AutoscalingMetric che indichi a GKE dove trovare la metrica e come esportarla:

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.

Una volta applicata, la metrica diventa disponibile al sistema di autoscaling.

Creiamo ora un HPA che utilizzi la metrica personalizzata.

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

In pratica, questa configurazione stabilisce che:

• se la dimensione media della coda supera i 20 job per pod, il sistema scala verso l'alto;
• se la coda si riduce, il sistema scala verso il basso.

Questa funzionalità offre diversi vantaggi chiave.

• Scaling consapevole dell'applicazione: le decisioni di scaling riflettono la domanda reale, non semplici proxy infrastrutturali.
• Minore complessità operativa: non servono adattatori esterni né pipeline di metriche complicate.
• Prestazioni migliori: le applicazioni scalano con maggiore precisione e rispondono più rapidamente ai picchi di carico.
• Utilizzo più efficiente delle risorse: i costi infrastrutturali calano perché lo scaling è allineato alla domanda effettiva.
• Strategie di autoscaling flessibili: i team possono definire policy a partire da qualsiasi metrica gauge esposta dall'applicazione, come profondità della coda, sessioni attive, render in attesa e molto altro.