Che cos'è il Kubernetes Cluster Autoscaler?
Il Kubernetes Cluster Autoscaler è un componente open source progettato per regolare automaticamente le dimensioni di un cluster Kubernetes in base alle esigenze attuali dei workloads. Funziona monitorando i pod che non riescono a essere schedulati per mancanza di risorse e, quando necessario, espande il cluster aggiungendo nuovi nodi. Viceversa, individua i nodi sottoutilizzati e riduce il cluster rimuovendo quelli non necessari, garantendo un utilizzo ottimale delle risorse e una maggiore efficienza dei costi.
Questo scaling dinamico aiuta a mantenere alta disponibilità e prestazioni elevate senza interventi manuali. Il Cluster Autoscaler supporta diversi cloud provider, tra cui AWS, Azure e Google Cloud, integrandosi perfettamente con i rispettivi servizi Kubernetes gestiti. Utilizza le API specifiche di ciascun provider per effettuare il provisioning e la dismissione dei nodi quando necessario, consentendo alle organizzazioni di reagire in tempo reale alle variazioni del traffico.
Questo contenuto fa parte di una serie di articoli sull'autoscaling di Kubernetes
In questo articolo:
- Cosa sono gli Helm chart?
- Tutorial: primi passi con il Cluster Autoscaler e Helm Chart
- Best practice per il Cluster Autoscaler Helm Chart
Cosa sono gli Helm chart?
Gli Helm chart sono pacchetti standardizzati per applicazioni Kubernetes, che contengono tutti i manifest e i template YAML necessari per definire, configurare e distribuire workloads complessi. Semplificano il processo di deployment raggruppando risorse applicative, dipendenze e valori di configurazione in un unico artefatto riutilizzabile. Gli Helm chart possono essere:
- Versionati
- Condivisi
- Archiviati in repository
Con gli Helm chart, i team possono automatizzare installazione, upgrade e rollback delle applicazioni, riducendo il rischio di errori umani e garantendo coerenza tra gli ambienti. Il motore di templating di Helm consente deployment personalizzabili, permettendo agli utenti di sovrascrivere i valori predefiniti tramite un file values o argomenti da riga di comando.
Quick Start: eseguire il Cluster Autoscaler con Helm Chart
Prerequisiti del Cluster Autoscaler Helm Chart
Prima di installare il chart del Cluster Autoscaler, assicurarsi di utilizzare Helm 3+ e Kubernetes 1.35.x o successivo. Azure AKS richiede Kubernetes 1.10 o successivo con RBAC abilitato.
Il Cluster Autoscaler simula internamente il comportamento dello scheduler di Kubernetes. Sebbene altre versioni di Kubernetes possano funzionare sovrascrivendo l'immagine del container, versioni non allineate possono introdurre sottili problemi di scheduling. Il chart attuale utilizza la versione v2 dell'API degli Helm chart, quindi le versioni di Helm precedenti alla 3 non sono supportate.
Se si sta migrando da una versione 1.X di cluster-autoscaler-chart, disinstallare quella release prima di installare cluster-autoscaler versione 9.0.0 o successiva. Le vecchie release 1.X del chart sono deprecate.
Step 1: aggiungere il repository Helm del Cluster Autoscaler
Il chart del Cluster Autoscaler viene installato dal percorso autoscaler/cluster-autoscaler. Prima dell'installazione, verificare che il repository contenente questo chart sia configurato nel proprio ambiente Helm.
Con le sole impostazioni predefinite, il chart non crea un deployment di autoscaling funzionante. Durante l'installazione è necessario configurare l'auto-discovery dei node group oppure node group statici. L'utilizzo combinato dei due approcci è sconsigliato.
Con l'auto-discovery, impostare autoDiscovery.clusterName ed eventuali valori specifici del provider richiesti. Per la configurazione statica, definire uno o più gruppi tramite autoscalingGroups o autoscalingGroupsnamePrefix.
Step 2: come installare il Cluster Autoscaler con Helm
Installare il chart con helm install, fornendo la configurazione richiesta dal proprio cloud provider. Per le configurazioni salvate in un file values, utilizzare:
helm install my-release autoscaler/cluster-autoscaler -f myvalues.yaml
I valori devono identificare i node group che l'autoscaler può gestire. È possibile configurare l'auto-discovery con autoDiscovery.clusterName, oppure definire esplicitamente i gruppi con le rispettive dimensioni minime e massime.
Dopo l'installazione, controllare i log dell'autoscaler per confermare che il loop principale sia in esecuzione. In caso contrario, ispezionare il pod generato e verificare gli argomenti passati al comando cluster-autoscaler.
Step 3: installare il Cluster Autoscaler su AWS con Helm
Su AWS, il Cluster Autoscaler può rilevare automaticamente gli Auto Scaling Group (ASG). Applicare a ogni ASG gestito i tag con le chiavi k8s.io/cluster-autoscaler/enabled e k8s.io/cluster-autoscaler/<CLUSTER NAME>. Sono rilevanti solo le chiavi dei tag.
Quindi installare il chart specificando il nome del cluster e la regione AWS:
helm install my-release autoscaler/cluster-autoscaler \
--set autoDiscovery.clusterName=<CLUSTER NAME> \
--set awsRegion=<YOUR AWS REGION>
È inoltre possibile fornire awsAccessKeyID e awsSecretAccessKey durante l'installazione. Per Amazon EKS, un'alternativa consiste nell'associare il service account dell'autoscaler a un ruolo IAM e passarne l'ARN tramite l'annotazione del service account.
Se non si desidera utilizzare l'auto-discovery, specificare gli ASG manualmente:
helm install my-release autoscaler/cluster-autoscaler \
--set "autoscalingGroups[0].name=your-asg-name" \
--set "autoscalingGroups[0].maxSize=10" \
--set "autoscalingGroups[0].minSize=1"
Il worker su cui viene eseguito l'autoscaler deve disporre delle autorizzazioni IAM necessarie per ispezionare e modificare le risorse AWS Auto Scaling pertinenti.
Contenuti correlati: consulti il nostro confronto Karpenter vs. Cluster Autoscaler
Step 4: aggiornare il Cluster Autoscaler Helm Chart
Quando si aggiornano installazioni meno recenti, occorre tenere conto delle modifiche di versione del chart. Le release dalla versione 9.0.0 in poi utilizzano il nome del chart cluster-autoscaler. Per passare da una release deprecata 1.X di cluster-autoscaler-chart, disinstallare prima l'installazione 1.X esistente e poi installare la versione 9.0.0 o successiva.
La versione 9.1.0 modifica inoltre il significato di envFromConfigMap, che deve contenere il nome di una ConfigMap referenziata da envFrom. Le configurazioni che dipendono dal comportamento precedente di envFromConfigMap devono rinominare questa impostazione in extraEnvConfigMaps.
Per riferimento, una release può essere rimossa con:
helm uninstall my-release
Questo comando elimina i componenti Kubernetes associati a quella release Helm. Prima di cambiare versione, verificare i valori di configurazione che potrebbero differire tra la versione del chart installata e quella di destinazione.
Best practice per il Cluster Autoscaler Helm Chart
Ecco alcune pratiche importanti da tenere a mente quando si lavora con il Cluster Autoscaler tramite Helm chart.
1. Applicare il right-sizing alle richieste di CPU e memoria
Il right-sizing delle richieste di CPU e memoria dei workloads è essenziale quando si utilizza il Cluster Autoscaler. Se le richieste sono troppo elevate, lo scheduler può effettuare un over-provisioning dei nodi, con conseguente spreco di risorse e aumento dei costi. Al contrario, richieste troppo basse rischiano di causare contesa sulle risorse e potenziale instabilità delle applicazioni.
Azioni chiave:
- Analizzare l'utilizzo storico delle risorse e impostare request e limit in base alle esigenze reali anziché a valori predefiniti o a stime.
- Rivedere e adeguare regolarmente queste impostazioni man mano che i workloads evolvono.
- Utilizzare gli strumenti di monitoraggio di Kubernetes per osservare il consumo di risorse in tempo reale e individuare opportunità di ottimizzazione.
Richieste di risorse accurate migliorano l'efficienza dell'autoscaler, garantendo che i nuovi nodi vengano aggiunti solo quando davvero necessario e che le risorse esistenti siano utilizzate in modo efficace.
2. Trattare il right-sizing dei workloads e l'autoscaling dei nodi come un unico sistema
Il right-sizing dei workloads e l'autoscaling dei nodi non dovrebbero essere gestiti separatamente. Le modifiche alle richieste di risorse delle applicazioni influiscono direttamente sul modo in cui l'autoscaler scala il cluster. Se i workloads sono costantemente in over-provisioning, l'autoscaler aggiungerà nodi inutilmente, mentre l'under-provisioning può portare a pod non schedulabili e prestazioni degradate. Coordinare questi processi aiuta a mantenere l'equilibrio tra disponibilità delle risorse e costi.
Azioni chiave:
- Implementare strumenti automatizzati o policy che adeguino contemporaneamente le richieste dei workloads e le dimensioni dei node group.
- Garantire una comunicazione regolare tra i team di sviluppo e operations, affinché le decisioni di scaling riflettano le reali esigenze delle applicazioni.
Trattando right-sizing e autoscaling come elementi interconnessi, è possibile ottenere un migliore utilizzo delle risorse, maggiore stabilità delle applicazioni ed efficienza dei costi.
Contenuti correlati: consulti la nostra guida al Kubernetes Vertical Pod Autoscaler
3. Rivedere continuamente l'utilizzo delle risorse
Il monitoraggio continuo dell'utilizzo delle risorse è fondamentale per mantenere una configurazione di autoscaling efficiente. Le allocazioni statiche di risorse diventano rapidamente obsolete con il variare delle esigenze delle applicazioni, causando inefficienze o problemi di prestazioni. Analizzare regolarmente i dati di utilizzo consente di apportare modifiche consapevoli alle richieste dei workloads e alle impostazioni dell'autoscaler.
Azioni chiave:
- Utilizzare le dashboard di Kubernetes e le piattaforme di monitoraggio per tracciare nel tempo l'utilizzo di CPU, memoria e nodi.
- Stabilire un processo di revisione periodica, ad esempio audit mensili o avvisi automatici per pattern di utilizzo anomali.
- Reagire rapidamente alle variazioni nel consumo di risorse per prevenire l'over-provisioning e garantire che il cluster scali in modo appropriato.
Una revisione continua favorisce un approccio proattivo, riducendo i costi operativi e mantenendo un ambiente reattivo.
4. Progettare i node group per un bin packing efficiente
Un bin packing efficiente consiste nel collocare i workloads sui nodi in modo da massimizzare l'utilizzo delle risorse e ridurre al minimo gli sprechi. Nella progettazione dei node group è importante selezionare tipi e dimensioni di istanza in linea con i profili dei propri workloads.
Azioni chiave:
- Evitare nodi troppo grandi o troppo piccoli, che portano a frammentazione o sottoutilizzo delle risorse.
- Raggruppare workloads simili per favorire pattern di utilizzo più prevedibili e semplificare la configurazione dell'autoscaler.
- Adeguare le configurazioni dei node group man mano che le applicazioni evolvono.
- Monitorare la distribuzione dei workloads e individuare opportunità per consolidare o suddividere i node group ai fini di un packing migliore.
Un bin packing efficiente riduce il numero totale di nodi necessari, ottimizza le prestazioni dell'autoscaler e abbassa i costi dell'infrastruttura sfruttando al meglio le risorse disponibili.
5. Assicurarsi che HPA e Cluster Autoscaler lavorino insieme
L'Horizontal Pod Autoscaler (HPA) e il Cluster Autoscaler devono essere configurati per operare in armonia e garantire uno scaling ottimale. L'HPA regola il numero di pod in base alle metriche dei workloads, mentre il Cluster Autoscaler gestisce i nodi sottostanti. Se l'HPA scala i pod oltre la capacità dei nodi disponibili, il Cluster Autoscaler deve poter aggiungere nodi con sufficiente rapidità per accoglierli. Configurazioni non allineate possono causare errori nello scheduling dei pod o un'allocazione di risorse non necessaria.
Azioni chiave:
- Coordinare policy e soglie di scaling tra HPA e Cluster Autoscaler.
- Monitorare l'interazione tra i due componenti, utilizzando metriche e log per individuare colli di bottiglia o ritardi nelle azioni di scaling.
- Regolare i target dell'HPA e i parametri del Cluster Autoscaler per ottenere uno scaling bilanciato e reattivo.
Garantire che i due componenti lavorino insieme riduce i tempi di inattività, migliora la disponibilità delle applicazioni e favorisce un utilizzo efficiente delle risorse.
Massimizzare l'efficienza del Cluster Autoscaler con PerfectScale
I node autoscaler come Cluster Autoscaler e Karpenter aggiungono e rimuovono nodi in base alla domanda, migliorando la disponibilità del cluster e riducendo i costi legati alle risorse inattive. Ma anche un autoscaler ben configurato incontra dei limiti quando i workloads sottostanti sono configurati male: i container in over-provisioning sprecano capacità e costringono l'autoscaler ad aggiungere più nodi del necessario, i container in under-provisioning causano eviction dei pod e pressione sui nodi, e un bin packing inefficiente lascia le risorse sottoutilizzate generando al contempo eventi di scaling superflui. PerfectScale affronta questi problemi a livello di workload e di nodo, così che la configurazione di autoscaling offra davvero l'efficienza promessa.
Funzionalità chiave di PerfectScale per l'autoscaling di Kubernetes:
- Rilevamento proattivo degli errori di configurazione: analizza continuamente i workloads per identificare e risolvere errori di configurazione come CPU Request Not Set, Memory Request Not Set e Memory Limit Not Set, prevenendo eviction imprevedibili, over-commitment dei nodi e autoscaling inefficiente.
- Right-sizing autonomo dei workloads: adegua istantaneamente le risorse dei workloads in base all'utilizzo reale e migliora il bin packing dei pod per aumentare l'efficienza dell'autoscaling, senza alcun intervento manuale.
- Visibilità su autoscaling group e node pool: offre visibilità su costi e utilizzo degli autoscaling group e dei node pool, per individuare le inefficienze in tutto il cluster.
- Selezione ottimale dei tipi di nodo: aiuta a scegliere tipi di nodo che migliorano l'utilizzo, garantiscono una distribuzione precisa delle risorse e massimizzano l'efficienza dei costi.
- Ampio supporto per gli autoscaler: funziona insieme a Karpenter, Cluster Autoscaler e Node Auto Provisioning, combinando l'ottimizzazione a livello di nodo con il right-sizing a livello di pod per un bin packing migliore e decisioni di scaling più rapide.
Scopra come massimizzare l'autoscaling dei nodi Kubernetes con PerfectScale