Scalabilità automatica pod orizzontale

Questa pagina fornisce una panoramica della scalabilità automatica orizzontale dei pod e spiega come funziona. Scopri inoltre come configurare e utilizzare la scalabilità automatica orizzontale dei pod sui cluster.

Horizontal Pod Autoscaler modifica la forma del carico di lavoro Kubernetes aumentando o diminuendo automaticamente il numero di pod in risposta al consumo di CPU o memoria da parte del carico di lavoro oppure in risposta a metriche personalizzate riportate in Kubernetes o a metriche esterne da origini esterne al cluster.

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

Perché utilizzare la scalabilità automatica orizzontale dei pod

Quando esegui per la prima volta il deployment del tuo carico di lavoro in un cluster Kubernetes, potresti non essere sicuro dei requisiti delle risorse e di come questi requisiti possano cambiare a seconda di pattern di utilizzo, dipendenze esterne o altri fattori. La scalabilità automatica orizzontale dei pod contribuisce a garantire che il carico di lavoro funzioni in modo coerente in diverse situazioni e ti consente di controllare i costi pagando per la capacità aggiuntiva solo quando ne hai bisogno.

Non è sempre facile prevedere gli indicatori che mostrano se il carico di lavoro è insufficiente o meno utilizzato. Horizontal Pod Autoscaler può scalare automaticamente il numero di pod nel carico di lavoro in base a una o più metriche dei seguenti tipi:

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

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

    Questo può essere utile se la tua applicazione è soggetta a colli di bottiglia di rete anziché CPU o memoria.

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

    Ad esempio, il carico di lavoro potrebbe aver bisogno di più CPU quando importa un numero elevato di richieste da una pipeline come Pub/Sub. Puoi creare una metrica esterna per la dimensione della coda e configurare Horizontal Pod Autoscaler in modo da aumentare automaticamente il numero di pod quando le dimensioni della coda raggiungono una determinata soglia e per ridurre il numero di pod quando si riducono.

Puoi combinare un Horizontal Pod Autoscaler con uno Vertical Pod Autoscaler, con alcune limitazioni.

Come funziona la scalabilità automatica orizzontale dei pod

Ogni Horizontal Pod Autoscaler configurato funziona utilizzando un loop di controllo. Esiste un Horizontal Pod Autoscaler separato per ogni flusso di lavoro. Ogni Horizontal Pod Autoscaler controlla periodicamente le metriche di un determinato carico di lavoro in base alle soglie di destinazione configurate e modifica automaticamente la forma del carico di lavoro.

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 questo valore.
  • Se specifichi un valore percentuale per CPU o memoria, Horizontal Pod Autoscaler 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 non elaborati o valori medi.

Il controller utilizza il valore medio o non elaborato per una metrica segnalata per produrre un rapporto e utilizza questa relazione per scalare automaticamente il carico di lavoro. Puoi leggere una descrizione dell'algoritmo Horizontal Pod Autoscaler nella documentazione del progetto Kubernetes.

Rispondere a più metriche

Se configuri un carico di lavoro per la scalabilità automatica in base a più metriche, il Horizontal Pod Autoscaler valuta ogni metrica separatamente e utilizza l'algoritmo di scalabilità per determinare la nuova scala del carico di lavoro in base a ognuna. 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 alla dimensione massima calcolata, ma non lo scale down.

Prevenire il thrashing

Il thrashing si riferisce a una situazione in cui il gestore della scalabilità automatica orizzontale dei pod tenta di eseguire successive azioni di scalabilità automatica prima che il carico di lavoro finisca di rispondere alle azioni di scalabilità automatica precedenti. Per evitare il thrashing, il Horizontal Pod Autoscaler sceglie il suggerimento più grande in base agli ultimi cinque minuti.

Limitazioni

  • Non utilizzare Horizontal Pod Autoscaler insieme al Vertical Pod Autoscaler sulla CPU o sulla memoria. Per altre metriche, puoi utilizzare Horizontal Pod Autoscaler con Vertical Pod Autoscaler.
  • Se hai un deployment, non configurare la scalabilità automatica orizzontale dei pod nel ReplicaSet o nel controller di replica che lo supporta. Quando esegui un aggiornamento in sequenza sul controller di deployment o di replica, questo viene sostituito da un nuovo controller di replica. Configura invece scalabilità automatica orizzontale dei podd sul deployment.
  • Non puoi utilizzare la scalabilità automatica orizzontale dei pod per i carichi di lavoro che non possono essere scalati, come i DaemonSet.
  • Con la scalabilità automatica orizzontale dei pod non puoi utilizzare metriche personalizzate o esterne per fare lo scale down fino a zero pod e poi fare lo scale up.
  • La scalabilità automatica orizzontale dei pod espone metriche come risorse Kubernetes, il che impone limitazioni sui nomi delle metriche, ad esempio nessun carattere maiuscolo o /. L'adattatore per le metriche potrebbe consentire la ridenominazione. Ad esempio, consulta l'operatore as di prometheus-adapter.

Scalabilità

Horizontal Pod Autoscaler non prevede un limite fisso al numero di oggetti HPA supportati. Tuttavia, al di sopra di un certo numero di oggetti HPA, il periodo tra i ricalcoli HPA potrebbe diventare più lungo dei 15 secondi standard.

  • Versione secondaria di GKE 1.21 o precedente: il periodo di ricalcolo deve rimanere entro 15 secondi con un massimo di 100 oggetti HPA.
  • GKE secondaria 1.22 o successiva: il periodo di ricalcolo deve rimanere entro 15 secondi con un massimo di 300 oggetti HPA.

Anche i seguenti fattori possono influire sulle prestazioni:

  • Il numero di metriche su cui scalare: ogni metrica aggiunge una chiamata di recupero per i calcoli dei suggerimenti, influenzando il periodo di ricalcolo.
  • Latenza dello stack delle metriche personalizzate: i tempi di risposta superiori a circa 50 millisecondi sarebbero superiori a quelli osservati con le metriche standard di Kubernetes, con ripercussioni sul periodo di ricalcolo.

Interazione con HorizontalPodAutoscaler oggetti

Puoi configurare Horizontal Pod Autoscaler per un carico di lavoro e ottenere informazioni sugli eventi di scalabilità automatica e su cosa li ha causati visitando la pagina Carichi di lavoro nella console Google Cloud.

Ogni Horizontal Pod Autoscaler 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 creare oggetti HorizontalPodAutoscaler anche utilizzando il comando kubectl autoscale.

Passaggi successivi