Cos'è l'autoscaling
L'autoscaling è una funzionalità disponibile nei cluster Kubernetes che consente di adattare automaticamente le risorse del cluster in base al carico di lavoro. In particolare, permette di aumentare o ridurre il numero di nodi attivi di un Node Pool, senza intervento manuale, in base alla capacità del cluster di schedulare nuovi Pod.
Il comportamento dell'autoscaler si basa su un'analisi continua dello stato del cluster. Il sistema interviene automaticamente in due situazioni principali:
- ci sono Pod in stato Pending perché non trovano risorse disponibili (scale-up);
- uno o più nodi risultano sottoutilizzati da un certo tempo e i Pod possono essere rilocati su altri nodi (scale-down).
Queste condizioni vengono valutate ogni 10 secondi (valore modificabile tramite il parametro
--scan-interval).
Questa funzionalità consente di bilanciare dinamicamente costi, prestazioni e disponibilità del cluster.
Perché usare l'autoscaling dei Node Pool
L'autoscaling è consigliato in tutti gli scenari in cui il carico applicativo del cluster può variare nel tempo. In particolare, è utile quando:
- i carichi aumentano o diminuiscono in fasce orarie o periodi prevedibili;
- possono verificarsi picchi improvvisi non pianificabili;
- è necessario ottimizzare le risorse disponibili per contenere i costi;
- si desidera ridurre le attività manuali di ridimensionamento del cluster.
Attivando l'autoscaling, la gestione del cluster risulta più efficiente perché:
- offre adattabilità, permettendo al cluster di adeguarsi automaticamente al carico effettivo;
- garantisce efficienza, mantenendo attivi solo i nodi strettamente necessari in ogni momento;
- assicura semplicità, riducendo il bisogno di monitoraggi e interventi manuali;
- favorisce l'ottimizzazione dei costi, rimuovendo in automatico i nodi inutilizzati.
L'autoscaling è particolarmente indicato in ambienti con carico variabile e necessità di continuità operativa senza presidio costante.
Il sistema supporta anche cluster con più Node Pool configurati con autoscaling, permettendo una gestione flessibile e differenziata delle risorse in base ai workload.
L'autoscaler è basato sul Cluster API Provider di Aruba, integrato nel sistema per garantire la compatibilità con i Node Pool.
La chiave API da usare per l'autoscaler
Per poter installare e attivare il componente autoscaler all'interno del cluster, devi disporre di una
chiave API valida. Questa chiave serve per autenticare il componente con l'infrastruttura Aruba Cloud.
Dovrai utilizzare i due valori che la compongono:
ClientID (parte pubblica) e
ClientSecret (parte segreta).
Come configurare l'autoscaling
Durante lo
scale-up, il sistema aggiunge nuovi nodi per eseguire i Pod in attesa. Durante lo
scale-down, rimuove automaticamente i nodi sottoutilizzati, rilocando i Pod attivi su altri nodi quando possibile.
Per abilitare correttamente l'autoscaling su un Node Pool, devi impostare due parametri fondamentali:
- numero minimo di nodi: il valore sotto cui il Node Pool non può scendere, anche in assenza di carico;
- numero massimo di nodi: il limite oltre cui l'autoscaler non potrà salire, anche in caso di Pod non schedulabili.
Il valore minimo deve essere uguale o inferiore al massimo. Una configurazione errata impedirà l'attivazione dell'autoscaling.
Definire correttamente questi limiti ti consente di:
- evitare sprechi di risorse causati da un sovradimensionamento automatico;
- assicurare la continuità operativa anche in presenza di picchi imprevisti;
- ottimizzare l'impatto economico.
Perché l'autoscaler funzioni correttamente, ogni Pod deve avere nei manifest YAML i parametri resources.requests per CPU e memoria. Senza queste indicazioni, il sistema non sarà in grado di stimare il fabbisogno di risorse e quindi non attiverà lo scaling.
Come rendere l'autoscaling attivo
Dopo aver configurato i valori minimi e massimi per l'autoscaling nel tuo Node Pool, devi installare il componente
autoscaler all'interno del cluster per renderlo operativo.
Puoi farlo in pochi passaggi utilizzando
Helm. Consulta la guida su come
attivare l'autoscaler.
Parametri più usati per la gestione dell'autoscaler
Di seguito trovi un elenco dei parametri più comuni che puoi utilizzare per personalizzare il comportamento dell'autoscaler. Questi valori possono essere specificati nella configurazione del componente durante l'installazione o successivamente, se necessario.
| Parametro |
Descrizione |
Predefinito |
--address |
Indirizzo e porta su cui l'autoscaler espone le metriche. |
:8085 |
--cordon-node-before-terminating |
Applica il cordon automatico ai nodi prima della terminazione. |
true |
--emit-per-nodegroup-metrics |
Esporta metriche dettagliate per ogni Node Pool. |
false |
--enable-proactive-scaleup |
Abilita lo scale-up anticipato basato su previsioni. |
false |
--enforce-node-group-min-size |
Assicura il rispetto del numero minimo di nodi per ogni Node Pool. |
false |
--frequent-loops-enabled |
Abilita un controllo più frequente dello stato del cluster. |
true |
--ignore-daemonsets-utilization |
Ignora l'utilizzo delle risorse da parte dei DaemonSet nel calcolo dello scale-down. |
false |
--ignore-mirror-pods-utilization |
Ignora i pod mirror nel calcolo dell'utilizzo delle risorse. |
false |
--max-drain-parallelism |
Numero massimo di nodi che possono essere svuotati contemporaneamente. |
1 |
--max-graceful-termination-sec |
Tempo massimo concesso per la terminazione dei pod durante lo scale-down. |
600 |
--max-nodes-per-scaleup |
Numero massimo di nodi aggiungibili in una singola operazione di scale-up. |
100 |
--max-pod-eviction-time |
Tempo massimo per l'evizione di un pod prima di terminare il nodo. |
120s |
--max-scale-down-parallelism |
Numero massimo di nodi che possono essere rimossi in parallelo. |
1 |
--node-delete-delay-after-taint |
Ritardo tra il taint di un nodo e la sua rimozione. |
30s |
--scale-down-delay-after-add |
Tempo di attesa dopo l’aggiunta di un nodo prima dello scale-down. |
10m |
--scale-down-delay-after-delete |
Tempo di attesa dopo la rimozione di un nodo prima di altri scale-down. |
10s |
--scale-down-delay-after-failure |
Tempo di attesa dopo un tentativo fallito di scale-down. |
3m |
--scale-down-enabled |
Abilita o disabilita lo scale-down dei nodi. |
true |
--scale-down-unneeded-time |
Tempo minimo per considerare un nodo come non necessario. |
10m |
--scale-down-utilization-threshold |
Soglia sotto la quale un nodo è considerato sottoutilizzato. |
0.5 |
--scale-up-from-zero |
Consente di avviare Node Pool con zero nodi se necessario. |
true |
--scan-interval |
Intervallo tra due scansioni successive dello stato del cluster. |
10s |
Come viene conteggiato il servizio di autoscaling
L'autoscaling non ha un costo aggiuntivo, ma incide sul totale delle risorse utilizzate nel cluster. Poiché il numero di nodi attivi può variare dinamicamente, anche i costi possono variare nel tempo. Il conteggio avviene sulla base dei nodi effettivamente in esecuzione in ogni momento. In particolare:
- i nodi attivi, inclusi quelli avviati automaticamente, sono sempre conteggiati come risorse utilizzate;
- i nodi rimossi dall'autoscaler non sono più conteggiati dal momento della disattivazione.
Se il valore massimo configurato per il Node Pool è molto superiore al minimo, il cluster potrebbe espandersi in modo rilevante durante i picchi, con un impatto significativo sui costi.
Per ottimizzare la spesa:
- imposta limiti min/max coerenti con i carichi previsti;
- monitora regolarmente l'andamento del numero di nodi attivi;
- considera di usare Node Pool separati per ambienti di test e produzione.