Scalabilità automatica orizzontale dei pod

Questa pagina fornisce una panoramica della scalabilità automatica orizzontale dei pod e spiega come funziona in Google Kubernetes Engine (GKE). Puoi anche leggere come configurare e utilizzare la scalabilità automatica orizzontale dei pod sui tuoi cluster.

Il gestore della scalabilità automatica orizzontale dei pod modifica la forma del carico di lavoro Kubernetes aumentando o diminuendo automaticamente il numero di pod in risposta al consumo di CPU o memoria del carico di lavoro oppure in risposta a metriche personalizzate segnalate da Kubernetes o a metriche esterne provenienti da origini esterne al cluster.

La scalabilità automatica orizzontale dei pod non modifica il numero di nodi in un cluster GKE. Per scalare automaticamente il numero di nodi nel cluster in base alle variazioni del numero di pod, puoi utilizzare il gestore della scalabilità automatica dei cluster.

Quando esegui il deployment iniziale del carico di lavoro in un cluster Kubernetes, potresti non avere la certezza dei requisiti di risorse. Questi requisiti potrebbero anche cambiare nel tempo a seconda dei modelli di utilizzo, delle dipendenze esterne o di altri fattori. La scalabilità automatica orizzontale dei pod contribuisce a garantire che il tuo workload funzioni in modo coerente in diverse situazioni e ti consente di controllare i costi pagando solo la capacità aggiuntiva quando ne hai bisogno.

Non è sempre facile prevedere gli indicatori che mostrano se il tuo carico di lavoro è sottoutilizzato o se le risorse sono insufficienti. Horizontal Pod Autoscaler può scalare automaticamente il numero di pod nel workload in base a una o più metriche dei seguenti tipi:

  • Utilizzo effettivo delle risorse: quando l'utilizzo di CPU o memoria utilizzata di un determinato pod supera una soglia. Può essere espresso come valore grezzo o come percentuale dell'importo richiesto dal pod per la risorsa.

  • Metriche personalizzate: basate su qualsiasi metrica segnalata da un oggetto Kubernetes in un cluster, ad esempio la frequenza delle richieste client al secondo o le scritture di I/O al secondo.

    Ciò può essere utile se la tua applicazione è soggetta a colli di bottiglia di rete, piuttosto che di CPU o memoria.

  • Metriche esterne: basate su una metrica di un'applicazione o di un servizio esterno al cluster.

    Ad esempio, il tuo workload potrebbe richiedere più CPU durante l'importazione di un numero elevato di richieste da una pipeline come Pub/Sub. Puoi creare una metrica esterna per le dimensioni della coda e configurare Horizontal Pod Autoscaler in modo che aumenti automaticamente il numero di pod quando le dimensioni della coda raggiungono una determinata soglia e riduca il numero di pod quando le dimensioni della coda diminuiscono.

Puoi combinare un gestore della scalabilità automatica orizzontale dei pod con un gestore della scalabilità automatica verticale dei pod, con alcune limitazioni.

Come funziona la scalabilità automatica orizzontale dei pod

Ogni gestore della scalabilità automatica orizzontale dei pod configurato funziona utilizzando un ciclo di controllo. Esiste un gestore della scalabilità automatica orizzontale dei pod separato per ogni workload. Ogni gestore della scalabilità automatica orizzontale dei pod controlla periodicamente le metriche di un determinato workload rispetto alle soglie target che configuri e modifica automaticamente la forma del workload.

Risorse per pod

Per le risorse allocate per pod, come la CPU, il controller esegue query sull'API delle metriche delle risorse per ogni container in esecuzione nel pod.

  • Se specifichi un valore non elaborato per CPU o memoria, viene utilizzato il valore.
  • Se specifichi un valore percentuale per la CPU o la memoria, il gestore della scalabilità automatica pod orizzontale calcola il valore di utilizzo medio come percentuale delle richieste di CPU o memoria del pod.
  • Le metriche personalizzate ed esterne sono espresse come valori grezzi o medi.

Il controller utilizza il valore medio o non elaborato per una metrica segnalata per produrre un rapporto e lo utilizza per la scalabilità automatica del workload. Puoi leggere una descrizione dell'algoritmo di scalabilità automatica orizzontale dei pod nella documentazione del progetto Kubernetes.

Rispondere a più metriche

Se configuri un workload per la scalabilità automatica in base a più metriche, il gestore della scalabilità automatica orizzontale dei pod valuta ogni metrica separatamente e utilizza l'algoritmo di scalabilità per determinare la nuova scalabilità del workload in base a ciascuna metrica. Per l'azione di scalabilità automatica viene selezionata la scala più grande.

Se una o più metriche non sono disponibili per qualche motivo, Horizontal Pod Autoscaler esegue comunque lo scale up in base alle dimensioni più grandi calcolate, ma non lo scale down.

Prevenire il thrashing

Il thrashing si riferisce a una situazione in cui l'Horizontal Pod Autoscaler tenta di eseguire azioni di scalabilità automatica successive prima che il workload finisca di rispondere alle azioni di scalabilità automatica precedenti. Per evitare il thrashing, il gestore della scalabilità automatica pod orizzontale sceglie il suggerimento più grande da una finestra di stabilizzazione specificata. Questo comportamento è controllato dal campo scaleDown.stabilizationWindowSeconds nella specifica HPA behavior, che per impostazione predefinita è di 300 secondi (5 minuti) in GKE.

Per evitare che piccole fluttuazioni causino eventi di scalabilità non necessari, il gestore della scalabilità automatica pod orizzontale utilizza un valore di tolleranza del 10%. Per un determinato target, non viene eseguita alcuna azione di scalabilità se il rapporto tra il valore attuale della metrica e il valore target della metrica rientra nel 10% di 1,0.

Scalabilità fino a zero e da zero

In GKE versione 1.37 o successive, puoi configurare il gestore della scalabilità automatica pod orizzontale in modo da ridurre le repliche di un carico di lavoro a 0 quando non c'è domanda e aumentare automaticamente il carico di lavoro quando la domanda riprende. Lo scaling da e verso zero include i seguenti comportamenti:

  • Ignora tolleranza: quando un workload ha 0 repliche, GKE ignora il controllo di tolleranza standard delle metriche (rapporto da 0,9 a 1,1). Qualsiasi valore della metrica maggiore di zero, ad esempio un singolo messaggio in una coda, attiva immediatamente lo scale up ad almeno 1 repliche senza attendere il superamento di una soglia di tolleranza.
  • Finestre di stabilizzazione: lo scale up è impostato su 0 secondi (scaleUp.stabilizationWindowSeconds: 0) per l'attivazione immediata, mentre lo scale down è impostato su 300 secondi (scaleDown.stabilizationWindowSeconds: 300) per garantire cinque minuti continui di domanda pari a zero prima di scalare a 0 repliche.
  • Condizioni di stato: quando viene scalato a 0 repliche dall'HPA, il controller segnala la condizione ScaledToZero: True rimanendo attivo (ScalingActive: True). Se un workload viene scalato manualmente a 0 repliche al di fuori dell'HPA (ad esempio con il comando kubectl scale), la scalabilità automatica si interrompe (ScalingActive: False) finché il workload non viene ridimensionato a 1 o più repliche.

Per istruzioni passo passo, vedi Scalare i carichi di lavoro GKE a zero e da zero utilizzando HPA.

Limitazioni

  • A meno che tu non utilizzi il dimensionamento corretto di HPA con VPA (anteprima), non utilizzare la scalabilità automatica pod orizzontale insieme alla scalabilità automatica pod verticale standard su CPU o memoria. Puoi utilizzare Horizontal Pod Autoscaler con Vertical Pod Autoscaler per altre metriche oppure configurare la scalabilità automatica multidimensionale dei pod per scalare orizzontalmente in base alla CPU e verticalmente in base alla memoria contemporaneamente.
  • Se hai un deployment, non configurare la scalabilità automatica orizzontale dei pod sul ReplicaSet o sul Replication Controller che lo supporta. Quando esegui un aggiornamento in sequenza sul deployment o sul controller di replica, questo viene sostituito da un nuovo controller di replica. Configura invece la scalabilità automatica orizzontale dei pod nello stesso deployment.
  • Non puoi utilizzare la scalabilità automatica orizzontale dei pod per i carichi di lavoro che non possono essere scalati, come i DaemonSet.
  • La scalabilità automatica orizzontale dei pod espone le metriche come risorse Kubernetes, il che impone limitazioni ai nomi delle metriche, ad esempio nessun carattere maiuscolo o "/". L'adattatore di metrica potrebbe consentire la ridenominazione. Ad esempio, consulta l'operatore prometheus-adapter as.
  • Il gestore della scalabilità automatica orizzontale dei pod non fa fare lo scale down se una delle metriche che è configurato per monitorare non è disponibile. Per verificare se hai metriche non disponibili, consulta Visualizzazione dei dettagli di un gestore della scalabilità automatica orizzontale dei pod.

Scalabilità

Sebbene l'Horizontal Pod Autoscaler non abbia un limite rigido al numero di oggetti HPA supportati, le sue prestazioni possono essere influenzate all'aumentare di questo numero. Nello specifico, il periodo tra i ricalcoli di HPA potrebbe diventare più lungo dei 15 secondi standard.

  • Nella versione secondaria di GKE 1.31 o 1.32, se è configurato il profilo HPA per il rendimento, il periodo di ricalcolo deve rimanere entro 15 secondi con un massimo di 1000 oggetti HPA. Scopri come configurare il profilo HPA per il rendimento.
  • In GKE versione secondaria 1.33 o successive, se è configurato il profilo HPA Performance, il periodo di ricalcolo deve rimanere entro 15 secondi con un massimo di 5000 oggetti HPA. Il profilo HPA per il rendimento è abilitato per impostazione predefinita su tutti i cluster che soddisfano i requisiti.
  • Se il profilo HPA per il rendimento non è configurato, il periodo di ricalcolo deve rimanere entro 15 secondi con un massimo di 300 oggetti HPA.

Anche i seguenti fattori possono influire sul rendimento:

  • Scalabilità su più metriche: ogni metrica aggiunge una chiamata di recupero per i calcoli dei suggerimenti, il che influisce sul periodo di ricalcolo.
  • La latenza dello stack delle metriche personalizzate: tempi di risposta superiori a circa 50 millisecondi sarebbero superiori a quelli generalmente osservati con le metriche Kubernetes standard, influenzando il periodo di ricalcolo.

Interagire con gli oggetti HorizontalPodAutoscaler

Puoi configurare un gestore della scalabilità automatica orizzontale dei pod per un workload e ottenere informazioni sugli eventi di scalabilità automatica e sulle relative cause visitando la pagina Workload nella console Google Cloud .

Ogni gestore della scalabilità automatica orizzontale dei pod esiste nel cluster come oggetto HorizontalPodAutoscaler. Puoi utilizzare comandi come kubectl get hpa o kubectl describe hpa HPA_NAME per interagire con questi oggetti.

Puoi anche creare oggetti HorizontalPodAutoscaler utilizzando il comando kubectl autoscale.

Passaggi successivi