Autoscaling Dei Nodi Kubernetes: Gestire Picchi Di Traffico Imprevedibili Senza Interventi Manuali

Il problema

Una piattaforma di dati in tempo reale gestiva un traffico imprevedibile: aggiornamenti elettorali, notizie dell’ultima ora e comunicati di mercato generavano in pochi minuti picchi improvvisi di milioni di richieste. Il team aveva provato l’Horizontal Pod Autoscaler (HPA) per scalare le repliche, ma non funzionava.

Perché? L’HPA scalava i pod, ma nel cluster non c’era spazio per ospitarli. I nuovi pod restavano “Pending” per sempre perché i nodi erano pieni. Il traffico si accodava e i client andavano in timeout. Il problema non era “quanti pod”, ma “quanti nodi”.

La sfida

Tutti gli approcci tradizionali di autoscaling fallivano:

• L’HPA da solo non basta: scala il numero di pod, ma il cluster non ha capacità
• Scaling manuale dei nodi: vanifica lo scopo di Kubernetes e non anticipa i picchi
• Vertical Pod Autoscaler: modifica la dimensione delle request, ma non risolve il problema della mancanza di spazio
• Sovradimensionamento: comprare nodi extra “per sicurezza” è uno spreco e costa
• Imprevedibilità: i picchi di traffico sono casuali e non si può sapere quando arriveranno

La soluzione

Abbiamo implementato Cluster Autoscaler con un corretto dimensionamento delle request dei pod:

Fase 1: dimensionamento delle request dei pod

• Analizzato l’utilizzo reale delle risorse di tutti i workload
• Impostate le request di CPU e memoria sul 95° percentile dell’utilizzo osservato (non su supposizioni)
• Eliminato il sovradimensionamento che sprecava il 60% della capacità
• Configurati i pod disruption budget per scalare in discesa in sicurezza

Fase 2: Cluster Autoscaler

• Installato Cluster Autoscaler per individuare i pod in stato pending
• Configurata l’aggiunta automatica di nodi quando i pod non possono essere schedulati
• Configurata la rimozione automatica dei nodi inattivi
• Integrato con i gruppi di scaling dei cloud provider (AWS, GCP, Azure)

Fase 3: gruppi di scaling e tipi di istanza

• Creati node pool separati per i diversi tipi di workload
• Istanze riservate per la capacità di base (sempre necessaria)
• Istanze Spot per i workload variabili (gestiscono i picchi a costi contenuti)
• Strategia di flotta mista per ridurre il rischio di interruzioni

Fase 4: monitoraggio e sicurezza

• Alert sui pod in pending (indicano capacità insufficiente)
• Tracciati gli eventi di scale-up e scale-down e i relativi tempi
• Testato il failover in caso di interruzione delle istanze Spot
• Documentato il comportamento dello scaling per il team

Risultati

Gestione del traffico:

• ✅ I picchi di traffico fanno scalare il cluster in automatico (nessun pod in pending)
• ✅ Tempo di scale-up: pod in esecuzione entro 2-3 minuti dall’inizio del picco
• ✅ Tempo di scale-down: 10 minuti dopo la fine del picco (in modo ordinato)
• ✅ Nessun timeout delle richieste dovuto alla capacità (prima erano frequenti)

Operatività:

• ✅ Nessuno scaling manuale dei nodi
• ✅ Lo scaling è prevedibile e verificabile
• ✅ Il team affronta con fiducia il traffico inatteso
• ✅ Configurazione semplice (basata su YAML, nessun codice custom)

Costi:

• ✅ Costi inferiori rispetto al sovradimensionamento manuale
• ✅ Le istanze Spot abbassano il costo di base del 60-70%
• ✅ Le istanze riservate garantiscono una base stabile
• ✅ Nessun sovradimensionamento “per sicurezza” che spreca denaro

Punti chiave

1. L’HPA risolve lo scaling a livello di pod, non la capacità del cluster: servono entrambi
2. Request corrette dei pod sono la base: senza, l’autoscaling non può funzionare bene
3. Cluster Autoscaler è semplice ed efficace: open source, indipendente dal cloud, osserva solo i pod in pending
4. Le istanze Spot sono sicure, con disruption budget adeguati e una strategia di flotta mista
5. Anche i carichi imprevedibili scalano bene, se il sistema reagisce alla domanda reale (pod in pending) e non a quella prevista