Autoscaling su GKE e Cloud Run

Su GKE l’autoscaling opera su tre assi che vanno tenuti distinti. L’Horizontal Pod Autoscaler (HPA) aggiunge o rimuove repliche di un pod in base a una metrica (CPU, memoria o metriche custom/external via Cloud Monitoring): serve per carichi che scalano bene in orizzontale, come le API stateless. Il Vertical Pod Autoscaler (VPA) regola invece le resource request/limit del singolo container, utile quando non conosci il dimensionamento corretto o quando il carico non parallelizza. Il cluster autoscaler aggiunge o rimuove nodi quando i pod restano Pending per mancanza di capacità o quando i nodi sono sottoutilizzati. HPA e VPA in modalità “auto” sulla stessa metrica (CPU) confliggono: è un errore classico, perché entrambi reagiscono allo stesso segnale.

Su Cloud Run le leve sono diverse: la concurrency (quante richieste gestisce in parallelo una singola istanza) e i min/max instances. Alzare la concurrency riduce il numero di istanze e quindi il costo, ma solo se il codice regge richieste concorrenti; impostare min instances > 0 elimina i cold start al prezzo di pagare istanze idle; il max instances protegge i backend a valle e mette un tetto al budget.

Rightsizing con i Recommender

Il Recommender (parte di Active Assist) genera suggerimenti basati sull’utilizzo osservato. Il VM rightsizing / machine type recommender propone di ridimensionare o cambiare tipo alle Compute Engine sotto o sovra-utilizzate; l’idle resource recommender individua VM, dischi persistenti e indirizzi IP inutilizzati. Su GKE, il VPA in modalità recommendation-only (updateMode Off) fornisce le request suggerite senza applicarle: ideale per un rightsizing consapevole. Il principio d’esame è: misura prima di dimensionare, e preferisci le raccomandazioni data-driven alle stime a occhio.

Ottimizzare i costi in modo strutturale

I committed use discount (CUD) scambiano un impegno di 1 o 3 anni su una quantità di risorse (vCPU/RAM o spesa) con uno sconto: si applicano al carico baseline stabile, non ai picchi, che restano più convenienti on-demand o con autoscaling. Sono complementari agli sconti automatici per uso sostenuto (sustained use discount). Le resource quota non riducono la spesa di per sé, ma pongono un tetto che previene consumi anomali. Il monitoraggio della spesa va fatto con i budget & alert su Cloud Billing e con l’export su BigQuery per analisi granulari. Sullo storage, scegliere la storage class giusta (Standard, Nearline, Coldline, Archive) in base alla frequenza d’accesso, automatizzando le transizioni con l’Object Lifecycle Management, è una leva di costo spesso trascurata.

Colli di bottiglia e caching

Ottimizzare le performance parte dalla diagnosi. Cloud Trace misura la latenza end-to-end e individua lo span lento; Cloud Profiler attribuisce il consumo di CPU e memoria alle singole funzioni. Non scalare orizzontalmente per mascherare un collo di bottiglia (una query non indicizzata, una dipendenza sincrona): scalare aumenta il costo senza risolvere la causa. Il caching riduce latenza e carico a monte: Cloud CDN per gli asset statici serviti da un external Application Load Balancer, Memorystore (Redis/Memcached) per i dati applicativi caldi. Più automatizzi il fix del collo di bottiglia, meno toil produci e più abbassi l’MTTR.

Trappole tipiche d’esame

  • HPA e VPA insieme sulla stessa metrica → conflitto: non usare VPA in modalità auto e HPA sulla stessa metrica (es. CPU); usa VPA su metriche diverse o in recommendation-only mode.
  • Cold start critici → min instances, non max: per eliminare i cold start su Cloud Run imposta min instances > 0; il max instances fissa solo il tetto e protegge i backend, non riscalda le istanze.
  • Carico con picchi → CUD sbagliati: applica i committed use discount solo alla baseline stabile; coprire i picchi con un impegno porta a pagare risorse non usate.
  • Pod Pending per capacità → cluster autoscaler, non HPA: se mancano nodi, l’HPA da solo non basta; serve il cluster autoscaler ad aggiungere nodi.
  • Latenza alta → prima misura, poi scala: usa Cloud Trace/Profiler per trovare il collo di bottiglia; scalare senza diagnosi alza i costi senza risolvere.
  • Dati ad accesso raro su Standard → storage class + lifecycle: sposta su Nearline/Coldline/Archive con Object Lifecycle Management invece di lasciare tutto su Standard.