Per padroneggiare completamente Kubernetes, è necessario conoscere i vari metodi per scalare le risorse del cluster: , è uno dei principali obiettivi di Kubernetes. Abbiamo preparato una panoramica ad alto livello dei meccanismi di autoscaling orizzontale e verticale e di come ridimensionare i cluster, oltre a raccomandazioni su come utilizzarli in modo efficace.
L'articolo è stato tradotto da un team che ha implementato l'autoscaling in .
Perché è importante considerare lo scaling
— uno strumento per la gestione delle risorse e l'orchestrazione. Certamente, è interessante sperimentare le fantastiche funzionalità di distribuzione, monitoraggio e gestione dei pod (un modulo pod è un gruppo di contenitori avviati in risposta a una richiesta).
Tuttavia, è importante considerare anche le seguenti questioni:
- Come scalare i moduli e le applicazioni?
- Come mantenere i contenitori funzionanti ed efficienti?
- Come rispondere alle costanti variazioni nel codice e nei carichi di lavoro degli utenti?
Configurare i cluster Kubernetes per bilanciare le risorse e le prestazioni può essere una sfida complessa, richiedendo competenze esperte sul funzionamento interno di Kubernetes. Il carico di lavoro della tua applicazione o dei tuoi servizi può variare durante il giorno o addirittura all'interno di un'ora, quindi è meglio considerare il bilanciamento come un processo continuo.
Livelli di autoscaling di Kubernetes
Un autoscaling efficace richiede coordinamento tra due livelli:
- Il livello dei pod, che include l'autoscaling orizzontale (Horizontal Pod Autoscaler, HPA) e verticale (Vertical Pod Autoscaler, VPA). Questo scalamento riguarda le risorse disponibili per i tuoi contenitori.
- Il livello del cluster, gestito dal sistema di autoscaling del cluster (Cluster Autoscaler, CA), che aumenta o diminuisce il numero di nodi all'interno del cluster.
Modulo di autoscaling orizzontale (HPA)
Come suggerisce il nome, l'HPA scala il numero di repliche dei pod. Come trigger per modificare il numero di repliche, la maggior parte dei devops utilizza il carico sulla CPU e sulla memoria. Tuttavia, è possibile scalare il sistema in base a , una loro o addirittura .
Schema di funzionamento ad alto livello dell'HPA:
- L'HPA controlla continuamente i valori delle metriche specificate al momento dell'impostazione, con un intervallo predefinito di 30 secondi.
- L'HPA tenta di aumentare il numero di moduli se viene raggiunta la soglia impostata.
- L'HPA aggiorna il numero di repliche all'interno del controller di distribuzione/replica.
- Il controller di distribuzione/replica quindi distribuisce tutti i moduli aggiuntivi necessari.
L'HPA avvia il processo di distribuzione dei moduli al raggiungimento della soglia delle metriche.
Quando si utilizza l'HPA, considerare quanto segue:
- L'intervallo di controllo predefinito dell'HPA è di 30 secondi. È impostato dal flag horizontal-pod-autoscaler-sync-period nel gestore del controller.
- L'errore relativo predefinito è del 10%.
- Dopo l'ultimo aumento del numero di moduli, l'HPA attende la stabilizzazione delle metriche per tre minuti. Questo intervallo è impostato dal flag horizontal-pod-autoscaler-upscale-delay.
- Dopo l'ultimo abbassamento del numero di moduli, l'HPA attende la stabilizzazione per cinque minuti. Questo intervallo è impostato dal flag horizontal-pod-autoscaler-downscale-delay.
- L'HPA funziona meglio con oggetti di distribuzione piuttosto che con i controllori di replica. L'autoscaling orizzontale non è compatibile con l'aggiornamento continuo (rolling update), che manipola direttamente i controllori di replica. Durante la distribuzione, il numero di repliche dipende direttamente dagli oggetti di distribuzione.
Autoscaling verticale dei pod
L'autoscaling verticale (VPA) assegna più (o meno) tempo della CPU o memoria ai pod esistenti. È adatto per i pod con stato (stateful) o senza stato (stateless), ma principalmente progettato per servizi stateful. Tuttavia, è possibile applicare il VPA anche a moduli senza stato, se è necessario regolare automaticamente la quantità di risorse inizialmente allocate.
Il VPA risponde anche a eventi OOM (out of memory, esaurimento di memoria). Per modificare il tempo della CPU e la quantità di memoria, è necessario riavviare i pod. Durante il riavvio, il VPA rispetta il budget di distribuzione (), per garantire il numero minimo necessario di moduli.
È possibile impostare un volume minimo e massimo delle risorse per ogni modulo. Ad esempio, è possibile limitare la memoria massima a 8 GB. Questo è utile se i nodi attuali non possono allocare più di 8 GB di memoria per il container. Le specifiche dettagliate e il funzionamento sono descritti in .
Inoltre, VPA ha una funzione interessante di raccomandazioni (VPA Recommender). Questa tiene traccia dell'uso delle risorse e degli eventi OOM di tutti i moduli, proponendo nuovi valori di memoria e tempo di CPU basati su un algoritmo intelligente che considera le metriche storiche. È disponibile anche un'interfaccia API che accetta un descrittore pod e restituisce i valori di risorse suggeriti.
È importante notare che VPA Recommender non tiene traccia del "limite" delle risorse. Questo può portare a una monopolizzazione delle risorse da parte dei moduli all'interno dei nodi. È meglio impostare un valore limite a livello di namespace per evitare un consumo eccessivo di memoria o tempo di CPU.
Schema di alto livello del funzionamento di VPA:
- VPA controlla continuamente i valori delle metriche specificati al momento dell'installazione, con un intervallo predefinito di 10 secondi.
- Se viene raggiunta una soglia stabilita, VPA cerca di modificare la quantità di risorse allocate.
- VPA aggiorna il numero di risorse all'interno del controller di deployment/replikazione.
- Al riavvio dei moduli, tutte le nuove risorse vengono applicate alle istanze create.
VPA aggiunge il numero necessario di risorse
Prendi in considerazione i seguenti punti quando utilizzi VPA:
- La scalabilità richiede un riavvio obbligatorio del pod. Questo è necessario per evitare comportamenti instabili dopo le modifiche. Per garantire affidabilità, i moduli vengono riavviati e distribuiti tra i nodi in base alle nuove risorse allocate.
- VPA e HPA non sono attualmente compatibili e non possono funzionare sugli stessi pod. Se utilizzi entrambi i meccanismi di scalabilità all'interno di uno stesso cluster, assicurati che le impostazioni non consentano loro di attivarsi sugli stessi oggetti.
- VPA imposta le richieste di risorse dei contenitori basandosi solo sull'uso passato e attuale. Non stabilisce limiti per l'uso delle risorse. Possono sorgere problemi con il funzionamento di applicazioni che iniziano a consumare sempre più risorse, portando Kubernetes a spegnere il pod.
- VPA è attualmente in fase di sviluppo. Preparati al fatto che nel prossimo futuro il sistema potrebbe subire alcune modifiche. Puoi leggere sulle e . Tra i piani c'è l'implementazione della compatibilità tra VPA e HPA, così come il deployment dei moduli insieme a politiche di autoscalamento verticale per essi (ad esempio, un'etichetta speciale 'requires VPA').
Autoscalamento del cluster Kubernetes
L'autoscalamento del cluster (Cluster Autoscaler, CA) modifica il numero di nodi in base al numero di pod in attesa. Il sistema controlla periodicamente la presenza di pod in attesa — e aumenta la dimensione del cluster se sono necessarie più risorse e se il cluster non supera i limiti impostati. CA interagisce con il fornitore di servizi cloud, richiedendo nodi aggiuntivi o liberando quelli inattivi. La prima versione pubblica di CA è stata presentata in Kubernetes 1.8.
Schema di alto livello del funzionamento di CA:
- CA controlla la presenza di moduli in attesa con un intervallo predefinito di 10 secondi.
- Se uno o più moduli sono in attesa a causa della mancanza di risorse disponibili nel cluster per la loro distribuzione, cerca di preparare uno o più nodi aggiuntivi.
- Quando il fornitore di servizi cloud allocato il nodo necessario, questo si unisce al cluster e diventa pronto per gestire i pod.
- Il piano di Kubernetes distribuisce i moduli in attesa sul nuovo nodo. Se dopo questo alcuni moduli rimangono ancora in attesa, il processo si ripete, e vengono aggiunti nuovi nodi al cluster.
Assegnazione automatica dei nodi del cluster nel cloud
Tieni presente quanto segue quando usi CA:
- CA garantisce che tutti i moduli nel cluster abbiano spazio per essere eseguiti, indipendentemente dal livello di utilizzo della CPU. Inoltre, cerca di garantire che nel cluster non ci siano nodi inutili.
- CA registra la necessità di scalare circa ogni 30 secondi.
- Dopo che un nodo diventa non necessario, CA attende per impostazione predefinita 10 minuti prima di scalare il sistema.
- Nel sistema di autoscalamento esistono concetti di espansori (expanders). Queste sono diverse strategie per scegliere il gruppo di nodi a cui verranno aggiunti nuovi nodi.
- Applicare responsabilmente l'opzione cluster-autoscaler.kubernetes.io/safe-to-evict (true). Se si installano molti pod o se molti di essi sono distribuiti su più nodi, si perderà sostanzialmente la capacità di ridurre le dimensioni del cluster.
- Usa , per evitare l'eliminazione dei pod, il che potrebbe provocare il guasto di parte della tua applicazione.
Come interagiscono tra loro i sistemi di autoscaling di Kubernetes
Per una perfetta armonia, è consigliato applicare l'autoscaling sia a livello di pod (HPA/VPA) che a livello di cluster. Interagiscono relativamente bene tra loro:
- HPA o VPA aggiornano le repliche dei pod o le risorse allocate per i pod esistenti.
- Se per il ridimensionamento programmato non ci sono sufficienti nodi, CA rileva i pod in attesa.
- CA provisiona nuovi nodi.
- I moduli vengono distribuiti sui nuovi nodi.
Sistema di scaling collaborativo di Kubernetes
Errori comuni nell'autoscaling di Kubernetes
Ci sono alcune problematiche comuni che i DevOps incontrano quando tentano di implementare l'autoscaling.
HPA e VPA dipendono da metriche e da alcune informazioni storiche. Se non ci sono risorse sufficienti allocate, i moduli saranno ridotti e non potranno generare metriche. In questo caso, l'autoscaling non verrà mai attuato.
L'operazione di scaling stesso è sensibile al tempo. Vogliamo che i moduli e il cluster si ridimensionino rapidamente — prima che gli utenti notino problemi o guasti. Pertanto, è importante considerare il tempo medio di scaling dei pod e del cluster.
Lo scenario ideale è di 4 minuti:
- 30 secondi. Aggiornamento delle metriche target: 30−60 secondi.
- 30 secondi. HPA controlla i valori delle metriche: 30 secondi.
- Meno di 2 secondi. I moduli pod vengono creati e passano allo stato di attesa: 1 secondo.
- Meno di 2 secondi. CA rileva i moduli in attesa e invia le richieste per preparare i nodi: 1 secondo.
- 3 minuti. Il fornitore cloud provisiona i nodi. K8s attende che siano pronti: fino a 10 minuti (dipende da vari fattori).
Lo scenario peggiore (più realistico) è di 12 minuti:
- 30 secondi. Aggiornamento delle metriche target.
- 30 secondi. HPA controlla i valori delle metriche.
- Meno di 2 secondi. I moduli pod vengono creati e passano allo stato di attesa.
- Meno di 2 secondi. CA rileva i moduli in attesa e invia le richieste per preparare i nodi.
- 10 minuti. Il fornitore cloud provisiona i nodi. K8s attende che siano pronti. I tempi di attesa variano in base a diversi fattori, come la latenza del fornitore, la latenza del sistema operativo e il funzionamento degli strumenti ausiliari.
Non confondere i meccanismi di scaling dei fornitori cloud con il nostro CA. Quest'ultimo funziona all'interno del cluster Kubernetes, mentre il meccanismo del fornitore cloud si basa sulla distribuzione dei nodi. Non sa cosa sta accadendo ai tuoi pod o alla tua applicazione. Questi sistemi operano parallelamente.
Come gestire lo scaling in Kubernetes
- Kubernetes è uno strumento di gestione delle risorse e orchestrazione. Le operazioni di gestione dei pod e delle risorse del cluster sono una pietra miliare nell'apprendimento di Kubernetes.
- Apprendi la logica di scalabilità dei pod tenendo conto di HPA e VPA.
- CA dovrebbe essere utilizzato solo se comprendi bene le esigenze dei tuoi pod e dei container.
- Per una configurazione ottimale del cluster, è necessario comprendere come i diversi sistemi di scaling lavorano insieme.
- Quando valuti i tempi di scaling, considera gli scenari migliori e peggiori.
Fonte: habr.com
