Per padroneggiare pienamente Kubernetes, è necessario conoscere diversi modi per ridimensionare le risorse del cluster: by , questo è uno dei compiti principali di Kubernetes. Abbiamo fornito una panoramica di alto livello dei meccanismi di scalabilità automatica orizzontale e verticale e di ridimensionamento dei cluster, nonché consigli su come utilizzarli in modo efficace.
Articolo tradotto dal team che ha implementato la scalabilità automatica in .
Perché è importante pensare alla scalabilità
- uno strumento per la gestione e l'orchestrazione delle risorse. Naturalmente, è bello armeggiare con le interessanti funzionalità di distribuzione, monitoraggio e gestione dei pod (un pod è un gruppo di contenitori che vengono lanciati in risposta a una richiesta).
Tuttavia, dovresti anche pensare alle seguenti domande:
- Come scalare moduli e applicazioni?
- Come mantenere i container operativi ed efficienti?
- Come rispondere ai continui cambiamenti nel codice e nei carichi di lavoro da parte degli utenti?
La configurazione dei cluster Kubernetes per bilanciare risorse e prestazioni può essere impegnativa e richiede una conoscenza approfondita del funzionamento interno di Kubernetes. Il carico di lavoro dell'applicazione o dei servizi può variare nell'arco della giornata o anche nel corso di un'ora, pertanto è meglio considerare il bilanciamento come un processo continuo.
Livelli di scalabilità automatica di Kubernetes
Una scalabilità automatica efficace richiede il coordinamento tra due livelli:
- Livello pod, incluso il ridimensionamento automatico orizzontale (Horizontal Pod Autoscaler, HPA) e verticale (Vertical Pod Autoscaler, VPA). Questo sta ridimensionando le risorse disponibili per i tuoi contenitori.
- Livello del cluster, gestito dal Cluster Autoscaler (CA), che aumenta o diminuisce il numero di nodi all'interno del cluster.
Modulo di scalabilità automatica orizzontale (HPA).
Come suggerisce il nome, HPA ridimensiona il numero di repliche di pod. La maggior parte dei devop utilizza il carico della CPU e della memoria come trigger per modificare il numero di repliche. Tuttavia, è possibile ridimensionare il sistema in base a loro o .
Schema operativo HPA di alto livello:
- L'HPA controlla continuamente i valori metrici specificati durante l'installazione con un intervallo predefinito di 30 secondi.
- L'HPA tenta di aumentare il numero di moduli se viene raggiunta la soglia specificata.
- L'HPA aggiorna il numero di repliche all'interno del controller di distribuzione/replica.
- Il controller di distribuzione/replica distribuisce quindi tutti i moduli aggiuntivi necessari.
HPA avvia il processo di distribuzione del modulo quando viene raggiunta una soglia metrica
Quando si utilizza HPA, considerare quanto segue:
- L'intervallo di controllo HPA predefinito è 30 secondi. È fissato dalla bandiera periodo di sincronizzazione-pod-autoscaler-orizzontale nella gestione del controllore.
- L'errore relativo predefinito è del 10%.
- Dopo l'ultimo aumento del numero di moduli, HPA prevede che i parametri si stabilizzino entro tre minuti. Questo intervallo è impostato dal flag orizzontale-pod-autoscaler-upscale-delay.
- Dopo l'ultima riduzione del numero di moduli, l'HPA attende cinque minuti per stabilizzarsi. Questo intervallo è impostato dal flag ritardo-downscale-pod-autoscaler-orizzontale.
- HPA funziona meglio con oggetti di distribuzione anziché con controller di replica. La scalabilità automatica orizzontale non è compatibile con l'aggiornamento in sequenza, che manipola direttamente i controller di replica. Con la distribuzione, il numero di repliche dipende direttamente dagli oggetti di distribuzione.
Scalabilità automatica verticale dei pod
La scalabilità automatica verticale (VPA) alloca più (o meno) tempo di CPU o memoria ai pod esistenti. Adatto per pod con stato o senza stato, ma destinato principalmente a servizi con stato. Tuttavia, puoi anche utilizzare VPA per i moduli stateless se hai bisogno di regolare automaticamente la quantità di risorse inizialmente allocate.
VPA risponde anche agli eventi OOM (memoria esaurita). La modifica del tempo della CPU e della memoria richiede il riavvio dei pod. Una volta riavviato, il VPA rispetta il budget di assegnazione () per garantire il numero minimo richiesto di moduli.
È possibile impostare le risorse minime e massime per ciascun modulo. Pertanto, puoi limitare la quantità massima di memoria allocata a 8 GB. Ciò è utile se i nodi attuali non possono assolutamente allocare più di 8 GB di memoria per contenitore. Le specifiche dettagliate e il meccanismo di funzionamento sono descritti in .
Inoltre, VPA dispone di un'interessante funzione di raccomandazione (VPA Recommender). Monitora l'utilizzo delle risorse e gli eventi OOM di tutti i moduli per suggerire nuovi valori di memoria e tempo di CPU sulla base di un algoritmo intelligente basato su metriche storiche. Esiste anche un'API che accetta un handle di pod e restituisce i valori delle risorse suggeriti.
Vale la pena notare che VPA Recommender non tiene traccia del "limite" delle risorse. Ciò potrebbe far sì che il modulo monopolizzi le risorse all'interno dei nodi. È preferibile impostare il limite a livello di spazio dei nomi per evitare un consumo eccessivo di memoria o CPU.
Schema operativo VPA di alto livello:
- VPA controlla continuamente i valori metrici specificati durante l'installazione con un intervallo predefinito di 10 secondi.
- Se viene raggiunta la soglia specificata, il VPA tenta di modificare la quantità di risorse allocate.
- Il VPA aggiorna il numero di risorse all'interno del controller di distribuzione/replica.
- Quando i moduli vengono riavviati, tutte le nuove risorse vengono applicate alle istanze create.
VPA aggiunge la quantità di risorse richiesta
Tieni presente i seguenti punti quando utilizzi VPA:
- Il ridimensionamento richiede un riavvio obbligatorio del pod. Ciò è necessario per evitare un funzionamento instabile dopo aver apportato modifiche. Per motivi di affidabilità, i moduli vengono riavviati e distribuiti tra i nodi in base alle risorse appena allocate.
- VPA e HPA non sono ancora compatibili tra loro e non possono essere eseguiti sugli stessi pod. Se utilizzi entrambi i meccanismi di dimensionamento nello stesso cluster, assicurati che le tue impostazioni ne impediscano l'attivazione sugli stessi oggetti.
- VPA ottimizza le richieste del contenitore per le risorse in base solo all'utilizzo passato e attuale. Non stabilisce limiti di utilizzo delle risorse. Potrebbero verificarsi problemi con le applicazioni che non funzionano correttamente e iniziano a occupare sempre più risorse, ciò porterà Kubernetes a disattivare questo pod.
- La VPA è ancora in una fase iniziale di sviluppo. Tieni presente che il sistema potrebbe subire alcune modifiche nel prossimo futuro. Puoi leggere di и . Pertanto, ci sono piani per implementare il funzionamento congiunto di VPA e HPA, nonché l'implementazione di moduli insieme a una politica di scalabilità automatica verticale per essi (ad esempio, un'etichetta speciale "richiede VPA").
Scalabilità automatica di un cluster Kubernetes
Cluster Autoscaler (CA) modifica il numero di nodi in base al numero di pod in attesa. Il sistema verifica periodicamente la presenza di moduli in sospeso e aumenta la dimensione del cluster se sono necessarie più risorse e se il cluster non supera i limiti stabiliti. La CA comunica con il fornitore di servizi cloud, gli richiede nodi aggiuntivi o rilascia quelli inattivi. La prima versione generalmente disponibile di CA è stata introdotta in Kubernetes 1.8.
Schema di alto livello del funzionamento SA:
- CA verifica la presenza di moduli in sospeso a un intervallo predefinito di 10 secondi.
- Se uno o più pod sono in stato di standby perché il cluster non dispone di risorse disponibili sufficienti per allocarli, tenta di eseguire il provisioning di uno o più nodi aggiuntivi.
- Quando il fornitore di servizi cloud alloca il nodo richiesto, si unisce al cluster ed è pronto a servire i pod.
- Lo scheduler Kubernetes distribuisce i pod in sospeso al nuovo nodo. Se successivamente alcuni moduli rimangono ancora in uno stato di attesa, il processo viene ripetuto e nuovi nodi vengono aggiunti al cluster.
Provisioning automatico dei nodi del cluster nel cloud
Considerare quanto segue quando si utilizza CA:
- CA garantisce che tutti i pod nel cluster dispongano di spazio per l'esecuzione, indipendentemente dal carico della CPU. Cerca inoltre di garantire che non siano presenti nodi non necessari nel cluster.
- CA registra la necessità di ridimensionare dopo circa 30 secondi.
- Una volta che un nodo non è più necessario, la CA attende per impostazione predefinita 10 minuti prima di espandere il sistema.
- Il sistema di scalabilità automatica utilizza il concetto di espansori. Queste sono diverse strategie per selezionare un gruppo di nodi a cui verranno aggiunti nuovi nodi.
- Utilizza l'opzione in modo responsabile cluster-autoscaler.kubernetes.io/safe-to-evict (vero). Se installi molti pod o se molti di essi sono sparsi su tutti i nodi, perderai in gran parte la capacità di scalare il cluster.
- Utilizzare per impedire l'eliminazione dei pod, che potrebbe causare la rottura completa di parti dell'applicazione.
Come gli autoscaler Kubernetes interagiscono tra loro
Per una perfetta armonia, la scalabilità automatica deve essere applicata sia a livello di pod (HPA/VPA) che a livello di cluster. Interagiscono tra loro in modo relativamente semplice:
- Gli HPA o i VPA aggiornano le repliche dei pod o le risorse allocate ai pod esistenti.
- Se non ci sono abbastanza nodi per lo scaling pianificato, la CA rileva la presenza di pod in stato di attesa.
- La CA alloca nuovi nodi.
- I moduli vengono distribuiti ai nuovi nodi.
Sistema collaborativo di scalabilità orizzontale Kubernetes
Errori comuni nella scalabilità automatica di Kubernetes
Esistono diversi problemi comuni in cui si imbattono i devops quando si tenta di implementare la scalabilità automatica.
HPA e VPA dipendono da parametri e da alcuni dati storici. Se vengono allocate risorse insufficienti, i moduli verranno ridotti al minimo e non saranno in grado di generare parametri. In questo caso, la scalabilità automatica non avverrà mai.
L'operazione di ridimensionamento stessa è sensibile al tempo. Vogliamo che i moduli e il cluster si ridimensionino rapidamente, prima che gli utenti notino eventuali problemi o guasti. Pertanto, è necessario prendere in considerazione il tempo di ridimensionamento medio per i pod e il cluster.
Scenario ideale - 4 minuti:
- 30 secondi. Aggiornamento delle metriche target: 30-60 secondi.
- 30 secondi. HPA controlla i valori metrici: 30 secondi.
- Meno di 2 secondi. I pod vengono creati e entrano nello stato di attesa: 1 secondo.
- Meno di 2 secondi. La CA vede i moduli in attesa e invia chiamate ai nodi di provisioning: 1 secondo.
- 3 minuti. Il fornitore di servizi cloud assegna i nodi. K8 attende finché non è pronto: fino a 10 minuti (a seconda di diversi fattori).
Scenario peggiore (più realistico) - 12 minuti:
- 30 secondi. Aggiorna le metriche target.
- 30 secondi. HPA controlla i valori metrici.
- Meno di 2 secondi. I pod vengono creati ed entrano nello stato di standby.
- Meno di 2 secondi. La CA vede i moduli in attesa ed effettua chiamate per effettuare il provisioning dei nodi.
- 10 minuti. Il fornitore di servizi cloud assegna i nodi. I K8 aspettano finché non sono pronti. Il tempo di attesa dipende da diversi fattori, come il ritardo del fornitore, il ritardo del sistema operativo e gli strumenti di supporto.
Non confondere i meccanismi di scalabilità dei fornitori di servizi cloud con la nostra CA. Quest'ultimo viene eseguito all'interno di un cluster Kubernetes, mentre il motore del fornitore di servizi cloud funziona sulla base della distribuzione dei nodi. Non sa cosa sta succedendo ai tuoi pod o alla tua applicazione. Questi sistemi funzionano in parallelo.
Come gestire la scalabilità in Kubernetes
- Kubernetes è uno strumento di gestione e orchestrazione delle risorse. Le operazioni per la gestione dei pod e delle risorse del cluster rappresentano una tappa fondamentale nella padronanza di Kubernetes.
- Comprendere la logica della scalabilità dei pod tenendo conto di HPA e VPA.
- CA dovrebbe essere utilizzato solo se hai una buona conoscenza delle esigenze dei tuoi pod e contenitori.
- Per configurare in modo ottimale un cluster, è necessario comprendere come interagiscono i diversi sistemi di scalabilità.
- Quando si stima il tempo di ridimensionamento, tenere a mente gli scenari peggiore e migliore.
Fonte: habr.com