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 informazioni su come configurare e utilizzare la scalabilità automatica orizzontale dei pod sui tuoi cluster.

Horizontal Pod Autoscaler modifica la forma del tuo workload Kubernetes aumentando o diminuendo automaticamente il numero di pod in risposta al consumo di CPU o memoria del workload oppure in risposta a metriche personalizzate segnalate da Kubernetes o a metriche esterne provenienti da origini esterne al cluster.

I cluster GKE con il provisioning automatico dei nodi scalano automaticamente il numero di nodi nel cluster in base alle variazioni del numero di pod. Per questo motivo, ti consigliamo di utilizzare la scalabilità automatica orizzontale dei pod per tutti i cluster.

Perché utilizzare la scalabilità automatica orizzontale dei pod

Quando esegui il deployment iniziale del workload in un cluster Kubernetes, potresti non avere la certezza dei suoi requisiti di risorse e di come questi potrebbero cambiare a seconda dei pattern 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 workload è sottodimensionato o sottoutilizzato. Horizontal Pod Autoscaler può scalare automaticamente il numero di pod nel tuo 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 riportata da un oggetto Kubernetes in un cluster, ad esempio la frequenza delle richieste client al secondo o le scritture I/O al secondo.

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

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

    Ad esempio, il tuo carico di lavoro potrebbe richiedere più CPU quando acquisisce 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 del pod orizzontale 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 la CPU o la memoria, viene utilizzato il valore.
  • Se specifichi un valore percentuale per la CPU o la memoria, la 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 è 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 verifica quando 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 la scalabilità automatica orizzontale dei pod in modo da scalare un workload fino a 0 repliche quando non c'è domanda e scalare automaticamente il workload di nuovo quando la domanda riprende. Lo scaling da e verso zero include i seguenti comportamenti:

  • Bypass della tolleranza: quando un carico di lavoro ha 0 repliche, GKE esegue il bypass del controllo della tolleranza della metrica standard (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 viene impostato per impostazione predefinita su 0 secondi (scaleUp.stabilizationWindowSeconds: 0) per l'attivazione immediata, mentre lo scale down viene impostato per impostazione predefinita 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

  • Non utilizzare la scalabilità automatica orizzontale dei pod insieme alla scalabilità automatica verticale dei pod su CPU o memoria. Puoi utilizzare il gestore della scalabilità automatica orizzontale dei pod con il gestore della scalabilità automatica verticale dei pod per altre metriche. Puoi configurare la scalabilità automatica multidimensionale dei pod (in versione beta) per scalare orizzontalmente la CPU e verticalmente la memoria contemporaneamente.
  • Se hai un deployment, non configurare la scalabilità automatica orizzontale dei pod sul ReplicaSet o sul controller di replica che lo supporta. Quando esegui un aggiornamento in sequenza del deployment o del 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 workload 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 della metrica potrebbe consentire la ridenominazione. Ad esempio, consulta l'operatore prometheus-adapter as.
  • Horizontal Pod Autoscaler non esegue 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'autoscaler orizzontale dei pod non abbia un limite rigido al numero di oggetti HPA supportati, le sue prestazioni possono essere influenzate all'aumentare di questo numero. In particolare, il periodo tra i ricalcoli di HPA potrebbe diventare più lungo dei 15 secondi standard.

  • Nella versione secondaria di GKE 1.22 o successive, il periodo di ricalcolo deve rimanere entro 15 secondi con un massimo di 300 oggetti HPA.
  • Nella versione secondaria di GKE 1.31 o successive, 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.
  • Nella versione secondaria di GKE 1.33 o successive, se è configurato il profilo HPA per il rendimento, il periodo di ricalcolo deve rimanere entro 15 secondi con un massimo di 5000 oggetti HPA. Il profilo HPA per il rendimento è attivato per impostazione predefinita su tutti i cluster che soddisfano i requisiti.

Anche i seguenti fattori possono influire sul rendimento:

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

Interazione 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