Il Cluster Autoscaler Helm chart è un modo per installare il Kubernetes Cluster Autoscaler, che aggiunge worker node quando i pod non possono essere schedulati e rimuove i nodi quando non servono più. Puoi installarlo con un singolo comando helm install, ma due fattori incidono molto sul suo buon funzionamento: le impostazioni che configuri e le resource request dei tuoi pod.
Questa guida copre entrambi gli aspetti, oltre a spiegare come il Cluster Autoscaler prende le decisioni di scaling. Imparerai come il Cluster Autoscaler decide quando aggiungere o rimuovere nodi, quale chart installare, come installarlo e verificarlo su EKS, AKS e GKE, quali valori Helm ne controllano il comportamento, come fare tuning per i cluster di grandi dimensioni e come risolvere i problemi di scaling più comuni.
Che cos'è il Cluster Autoscaler Helm chart?
Il Cluster Autoscaler modifica il numero di nodi del cluster in base alle esigenze dei pod. Aggiunge nodi quando i pod non possono essere schedulati per mancanza di capacità e rimuove i nodi non più necessari quando i loro pod possono girare su altri nodi.
Lo fa modificando la dimensione dei node group del cloud provider, come gli Auto Scaling Group (ASG) di AWS, i Virtual Machine Scale Set (VMSS) di Azure o i Managed Instance Group (MIG) di Google Compute Engine.
L'Helm chart raggruppa in un'unica installazione il Deployment del Cluster Autoscaler, le relative autorizzazioni RBAC e la configurazione. Questo ne semplifica installazione, gestione e aggiornamento. Il Cluster Autoscaler scala i nodi, mentre l'HPA e KEDA scalano i pod.
Come decide il Cluster Autoscaler quando aggiungere e rimuovere i nodi?
Questi sono i fattori principali che il Cluster Autoscaler usa per decidere quando aggiungere o rimuovere nodi:
I pod in Pending attivano lo scale-up
Ogni 10 secondi, in base all'impostazione --scan-interval, l'autoscaler cerca i pod bloccati in Pending perché non trovano posto sui nodi esistenti. Verifica se un nuovo nodo di ciascun node group potrebbe eseguire quei pod, sceglie un gruppo adatto e ne aumenta la dimensione desiderata in modo che il cloud provider possa aggiungere un nodo. Se non ci sono pod non schedulabili, il Cluster Autoscaler non aggiunge nodi.
Un basso utilizzo e un tempo di attesa attivano lo scale-down
Quando non è necessario aggiungere nodi, l'autoscaler verifica se qualche nodo può essere rimosso. Un nodo diventa candidato quando le request di CPU e memoria dei suoi pod sono sotto la soglia --scale-down-utilization-threshold, il cui valore predefinito è 0.5 (50%). Il nodo deve rimanere sottoutilizzato per il tempo impostato da --scale-down-unneeded-time, che per impostazione predefinita è di 10 minuti. L'autoscaler attende inoltre dopo uno scale-up prima di rimuovere i nodi, in base a --scale-down-delay-after-add, anch'esso con un valore predefinito di 10 minuti. Ecco perché lo scale-down è in genere più lento dello scale-up.
Node group ed expander determinano da dove arrivano i nuovi nodi
L'autoscaler deve sapere quali node group gestire. Può individuarli automaticamente o usare un elenco esplicito. Se più node group possono eseguire i pod in Pending, l'impostazione --expander decide quale gruppo far crescere. Le opzioni sono random, most-pods, least-waste, price e priority.
Le resource request guidano le decisioni di scaling
È uno degli aspetti più importanti da capire. Il Cluster Autoscaler usa le resource request dei pod, non l'utilizzo effettivo di CPU e memoria. Aggiunge nodi quando le risorse richieste non trovano posto e considera sottoutilizzato un nodo in base alle request dei suoi pod. Ad esempio, se i pod richiedono l'80% della capacità di un nodo ma ne usano solo il 20%, l'autoscaler continua a vedere il nodo utilizzato all'80% e potrebbe non rimuoverlo. Request sovradimensionate possono quindi mantenere attivi nodi superflui e far crescere i costi cloud.
Quale chart del Cluster Autoscaler installare?
Per le nuove installazioni, usa il chart ufficiale autoscaler/cluster-autoscaler del repository kubernetes/autoscaler.
Potresti ancora trovare i vecchi chart stable/aws-cluster-autoscaler e stable/cluster-autoscaler. Sono deprecati e non più mantenuti, quindi evitali.
Helm non è l'unica opzione. I servizi Kubernetes gestiti possono fornire il Cluster Autoscaler tramite i propri strumenti e alcuni team lo gestiscono con Terraform. La scelta giusta dipende da come gestisci il tuo cluster.
Prerequisiti e compatibilità delle versioni
Prima dell'installazione, ecco le due cose da verificare:
Allinea la versione del Cluster Autoscaler a quella di Kubernetes
Dovresti usare il Cluster Autoscaler v1.30.x con Kubernetes 1.30, la v1.31.x con Kubernetes 1.31 e così via. L'autoscaler usa una propria logica di scheduling per verificare se un pod può trovare posto su un nuovo nodo, quindi una versione non allineata può portare a decisioni di scaling errate. Controlla il tag immagine predefinito del chart e, se necessario, fissalo alla versione corretta.
Concedi al Cluster Autoscaler l'accesso al tuo cloud provider
L'autoscaler ha bisogno dell'autorizzazione per modificare la dimensione dei node group e deve sapere quali node group gestisce. Su AWS questo significa disporre delle autorizzazioni IAM richieste e di Auto Scaling Group (ASG) correttamente taggati. Su Azure e GCE servono le autorizzazioni equivalenti e VM Scale Set (VMSS) o Managed Instance Group (MIG) configurati correttamente.
Assicurati che autorizzazioni e impostazioni dei node group siano corrette prima di installare. Il chart può avviarsi senza errori anche quando sono sbagliate, ma il Cluster Autoscaler non riuscirà a scalare i nodi.
Installare il chart su un cluster in esecuzione
Per prima cosa, aggiungi il repository ufficiale:
helm repo add autoscaler https://kubernetes.github.io/autoscalerhelm repo updatePrima di installare, devi indicare al Cluster Autoscaler quali node group gestire. La configurazione dipende dal cloud provider.
Su AKS e GKE gestiti, l'autoscaling dei nodi è già disponibile come funzionalità integrata da abilitare a livello di node pool, quindi in questi casi di solito non è necessario installare questo Helm chart. Il chart è utile soprattutto per Amazon EKS e per i cluster self-managed.
Installazione su EKS
Su EKS l'auto-discovery è l'approccio più semplice. Per prima cosa, tagga ogni Auto Scaling Group (ASG) che vuoi far gestire al Cluster Autoscaler con k8s.io/cluster-autoscaler/enabled e k8s.io/cluster-autoscaler/<your-cluster-name>.
Poi installa il chart:
helm install cluster-autoscaler autoscaler/cluster-autoscaler \ --namespace kube-system \ --set cloudProvider=aws \ --set autoDiscovery.clusterName=<your-cluster-name> \ --set awsRegion=<your-region>Installazione su Azure o GCE self-managed
Per un cluster Azure o GCE self-managed, imposta cloudProvider=azure o cloudProvider=gce e fornisci i dettagli degli scale set o instance group che vuoi far gestire al Cluster Autoscaler.
Le impostazioni esatte variano in base al cloud provider, ma la configurazione di base è la stessa: specifica il cloud provider, i node group e le credenziali o l'identità che il Cluster Autoscaler deve usare.
Dopo l'installazione, verifica che il pod del Cluster Autoscaler sia in esecuzione:
kubectl get pods -n kube-system -l app.kubernetes.io/instance=cluster-autoscalerPoi controllane lo stato:
kubectl describe configmap cluster-autoscaler-status -n kube-systemLa ConfigMap di stato mostra la dimensione di ciascun node group e le attività recenti di scale-up o scale-down. Ti dà un colpo d'occhio immediato per capire se il Cluster Autoscaler è in esecuzione e sta prendendo decisioni di scaling.
I valori Helm che modificano il comportamento dell'autoscaler
Ecco i valori più importanti:
cloudProvider e autoDiscovery
Indicano al Cluster Autoscaler quale cloud provider usi e come individuare i node group da gestire. Se sono errati, l'autoscaler non ha node group da scalare.
Annotazioni del service account per l'accesso al cloud
Puoi assegnare al Cluster Autoscaler autorizzazioni cloud dedicate tramite il suo service account, invece di concedere autorizzazioni ampie a tutti i nodi. Su EKS si usa in genere IAM Roles for Service Accounts (IRSA). Su Azure e GCE si può usare Workload Identity. Le annotazioni del service account si configurano con rbac.serviceAccount.annotations.
extraArgs per il comportamento di scaling
Con extraArgs imposti le opzioni del Cluster Autoscaler come scan-interval, scale-down-utilization-threshold, scale-down-unneeded-time ed expander. Puoi anche usare expendable-pods-priority-cutoff per definire la priorità sotto la quale i pod possono essere considerati sacrificabili. Queste impostazioni controllano la frequenza con cui l'autoscaler analizza il cluster e il modo in cui sceglie i nodi da aggiungere o rimuovere.
Numero di repliche, leader election e risorse
Per l'alta disponibilità puoi eseguire più di una replica. Il Cluster Autoscaler usa la leader election, quindi una sola replica è attiva alla volta mentre le altre sono pronte a subentrare. Imposta anche request e limit di CPU e memoria per l'autoscaler. I cluster di grandi dimensioni possono richiedere più memoria, perché l'autoscaler mantiene in memoria lo stato del cluster.
Puoi definire questi valori in un file values.yaml e installare il chart con -f:
cloudProvider: awsautoDiscovery: clusterName: my-clusterawsRegion: us-east-1replicaCount: 2extraArgs: scan-interval: 10s scale-down-utilization-threshold: "0.5" expander: least-waste balance-similar-node-groups: "true"resources: requests: cpu: 100m memory: 300Mi limits: cpu: 200m memory: 500MiTuning del chart per cluster grandi o multi-tenant
I cluster di grandi dimensioni richiedono un tuning aggiuntivo, perché a ogni scansione il Cluster Autoscaler ha più pod, nodi e node group da controllare. Alcune impostazioni e pattern aiutano a mantenerlo efficiente man mano che il cluster cresce:
Riduci il numero di node group
Più node group l'autoscaler gestisce, più lavoro deve svolgere a ogni scansione. Dove possibile, mantieni basso il numero di node group e usa i tag di auto-discovery per includere solo i gruppi che hanno bisogno di autoscaling.
Usa lo sharding per cluster molto grandi
Puoi eseguire più istanze del Cluster Autoscaler, ciascuna delle quali gestisce un insieme diverso di node group. In questo modo il lavoro si distribuisce su più istanze dell'autoscaler. Lo svantaggio è che queste istanze non si coordinano tra loro, quindi due di esse potrebbero reagire allo stesso pod in Pending e aggiungere temporaneamente più nodi del necessario. I nodi in eccesso possono essere rimossi in seguito durante lo scale-down.
Usa nodi Spot con il priority expander
Per i cluster orientati al contenimento dei costi puoi abbinare node group Spot al priority expander. In questo modo l'autoscaler privilegia la capacità Spot, più economica, e ricorre ai nodi on-demand quando serve.
Usa l'overprovisioning per uno scaling più rapido
L'overprovisioning usa pod segnaposto a bassa priorità per riservare capacità extra nel cluster. Quando arrivano i workloads reali, questi pod segnaposto vengono rimossi per fare spazio mentre l'autoscaler aggiunge nuovi nodi.
Scala i node group da zero
Un node group può scalare fino a zero quando non viene utilizzato. È particolarmente utile per i costosi node group GPU. Su EKS, assicurati che il node group abbia le label e i taint richiesti nei suoi tag per l'autoscaler, così il Cluster Autoscaler sa cosa possono offrire i nodi anche quando il gruppo è a zero nodi.
Diagnosticare un'installazione che non scala
Quando il Cluster Autoscaler non scala come previsto, la ConfigMap di stato e i log del pod sono i punti migliori da cui partire. Ecco i casi più comuni:
I pod restano in Pending e non vengono aggiunti nodi
Parti da kubectl describe pod <pod-name> e controlla gli eventi del pod. Poi esamina i log del Cluster Autoscaler. Le cause più comuni includono un node group già alla dimensione massima, nessun node group con capacità sufficiente per le resource request del pod, oppure node selector o affinity del pod che non corrispondono ad alcun node group disponibile. Anche autorizzazioni cloud o tag dei node group mancanti possono impedire all'autoscaler di trovare o modificare il node group.
I nodi restano sottoutilizzati e non vengono rimossi
Per impostazione predefinita il Cluster Autoscaler salta alcuni nodi. Ad esempio, salta i nodi che eseguono pod kube-system quando --skip-nodes-with-system-pods è abilitato e i nodi con pod che usano storage locale quando --skip-nodes-with-local-storage è abilitato. Inoltre attende durante il ritardo di scale-down. Ancora più importante, ricorda che il Cluster Autoscaler usa le resource request, non l'utilizzo effettivo. Se le request mantengono un nodo sopra la soglia di utilizzo, il nodo non diventerà candidato alla rimozione anche quando l'uso effettivo di CPU e memoria è basso.
Annotazioni e PodDisruptionBudget bloccano la rimozione dei nodi
Il Cluster Autoscaler non rimuove un nodo se farlo violerebbe un PodDisruptionBudget (PDB). Salta inoltre i pod con cluster-autoscaler.kubernetes.io/safe-to-evict: "false" e i nodi con l'annotazione scale-down-disabled. Queste impostazioni proteggono i workloads da eviction indesiderate, ma un'impostazione vecchia o superflua può tenere attivo un nodo più a lungo del previsto. Controlla kubectl describe configmap cluster-autoscaler-status -n kube-system per vedere quali nodi non possono essere rimossi e perché.
Strumenti che lavorano insieme al Cluster Autoscaler
Il Cluster Autoscaler gestisce il numero di nodi, ma gli strumenti seguenti possono aiutare con il dimensionamento dei pod e il provisioning dei nodi.
PerfectScale
Il Cluster Autoscaler prende le decisioni di scaling in base alle resource request dei pod, non all'utilizzo effettivo di CPU e memoria. Se le request sono troppo alte, può aggiungere nodi che non servono e mantenere nodi che altrimenti potrebbero essere rimossi. PerfectScale monitora l'utilizzo effettivo dei workloads e fornisce raccomandazioni automatizzate di right-sizing per avvicinare le request di CPU e memoria all'uso reale. Questo aiuta il Cluster Autoscaler a prendere decisioni di scaling migliori. Puoi provarlo subito o prenotare una sessione tecnica.
Vertical Pod Autoscaler (VPA) e Goldilocks
Il VPA regola le resource request dei pod in base all'utilizzo osservato. Goldilocks offre una dashboard per consultare le raccomandazioni del VPA. Entrambi possono aiutare a mantenere le resource request più vicine all'uso effettivo, fornendo al Cluster Autoscaler informazioni migliori per le sue decisioni di scaling.
Karpenter
Karpenter adotta un approccio diverso allo scaling dei nodi. Invece di ridimensionare node group fissi, può effettuare il provisioning dei nodi in base ai requisiti dei pod in Pending.
Best practice per il Cluster Autoscaler in produzione
Ecco le pratiche che aiutano a mantenere l'autoscaling dei nodi efficiente e sicuro:
1. Fai il right-sizing delle request dei pod prima di modificare le impostazioni dell'autoscaler
Il Cluster Autoscaler prende le sue decisioni in base alle resource request dei pod, quindi avere request accurate è più importante che modificare le impostazioni dell'autoscaler. Prima vanno corrette le resource request, poi si regolano timer ed expander.
2. Mantieni i node group omogenei per CPU, memoria e availability zone
I nodi all'interno dello stesso node group dovrebbero essere simili. Tipi di istanza o availability zone diversi possono rendere meno accurata la simulazione di scheduling dell'autoscaler. I node group simili possono essere bilanciati con balance-similar-node-groups.
3. Imposta PodDisruptionBudget per i workloads che non devono essere interrotti
Un PodDisruptionBudget (PDB) definisce quanti pod possono essere non disponibili contemporaneamente. Aiuta il Cluster Autoscaler a rimuovere i nodi mantenendo un numero sufficiente di repliche disponibili per il workload.
4. Fissa la versione del chart e testa gli aggiornamenti
La versione del Cluster Autoscaler deve corrispondere a quella di Kubernetes. Un aggiornamento di Kubernetes va quindi testato con la versione corrispondente dell'autoscaler prima che la modifica arrivi in produzione.
5. Esporta le metriche dell'autoscaler in Prometheus e imposta alert sugli scale-up falliti
Il Cluster Autoscaler espone metriche Prometheus che mostrano l'attività di scaling e gli errori. Alert sugli scale-up falliti e sui pod che restano in Pending aiutano a individuare i problemi prima che abbiano un impatto prolungato sui workloads.
6. Rivedi le soglie di scale-down alla luce dei risparmi effettivi
Uno scale-down aggressivo può ridurre i costi, ma i workloads con picchi di traffico improvvisi rischiano di fare scale-up e scale-down troppo spesso. La scale-down-utilization-threshold e i timer di scale-down possono essere regolati in base ai pattern di traffico reali, anziché essere ottimizzati solo per ridurre il numero di nodi.