Strategie per ridurre la latenza di avvio

Google Kubernetes Engine (GKE) offre diverse strategie che consentono di ridurre la latenza di avvio dei pod quando i carichi di lavoro aumentano. Riducendo i ritardi nel provisioning dei nodi, nei pull delle immagini container e nell'inizializzazione delle applicazioni, puoi contribuire a migliorare la reattività del servizio durante i picchi di traffico e a bilanciare i costi dell'infrastruttura.

Utilizza questo documento per confrontare le strategie di riduzione della latenza di avvio di GKE durante il ciclo di vita di avvio dei pod e scegliere una singola strategia o una combinazione a livelli adatta ai requisiti del tuo carico di lavoro.

Comprendere il ciclo di vita di avvio dei pod

Quando un carico di lavoro aumenta in GKE e i nodi esistenti non hanno una capacità allocabile sufficiente per i nuovi pod, la latenza di avvio end-to-end si estende su tre fasi sequenziali:

  • Durante la fase di provisioning dei nodi e di pianificazione dei pod, il gestore della scalabilità automatica del cluster esegue il provisioning di una nuova VM di Compute Engine, inizializza il nodo e lo registra con il piano di controllo in modo che lo scheduler Kubernetes possa inserire il pod in attesa.
  • Durante la fase di pull delle immagini container, il componente kubelet sul nodo scarica e decomprime le immagini container richieste dal pod dal Container Registry.
  • Durante la fase di inizializzazione dell'applicazione, il runtime del container avvia il processo dell'applicazione, carica le dipendenze o i pesi del modello in memoria e supera i probe di avvio e di idoneità di Kubernetes.

Diverse funzionalità di GKE sono destinate a fasi specifiche di questo ciclo di vita. Per scoprire quale fase contribuisce maggiormente al tempo di avvio del carico di lavoro, consulta Monitorare le metriche della latenza di avvio.

Confrontare le strategie di riduzione della latenza di avvio

La seguente tabella confronta le strategie di riduzione della latenza di avvio di GKE durante il ciclo di vita di avvio dei pod:

Strategia Fase del ciclo di vita Profilo di latenza Profilo di costi e quote Modalità cluster e supporto hardware Ideale per
Buffer di capacità attiva (anteprima) Provisioning dei nodi e pianificazione dei pod Pianificazione immediata dei pod perché i nodi sono già in esecuzione.

Tariffe di calcolo standard basate sui nodi per le VM in esecuzione.

Consuma le quote di vCPU, memoria, disco e indirizzo IP di Compute Engine quote, oltre alle quote di risorse Kubernetes nello spazio dei nomi.

Cluster standard e cluster Autopilot con ComputeClass personalizzate (fatturazione basata sui nodi).

Supporta CPU, GPU e TPU.

 Assorbire picchi di traffico improvvisi e scalare carichi di lavoro GPU, TPU o CPU sensibili alla latenza.
Buffer di capacità di standby (anteprima) Provisioning dei nodi e pianificazione dei pod Riprende i nodi sospesi in circa 30-35 secondi, il che è più veloce del provisioning di un nuovo nodo.

Nessun addebito di calcolo VM durante la sospensione. Comporta addebiti di archiviazione Persistent Disk per i dischi di avvio e lo stato della memoria archiviato.

Consuma le quote di disco e indirizzo IP durante la sospensione, oltre alle quote di risorse Kubernetes nello spazio dei nomi.

Cluster standard (con provisioning automatico dei nodi) e cluster Autopilot con ComputeClass personalizzate.

Supporta solo le CPU (no GPU, TPU o SSD locali).

 Mantenere una capacità di burst economicamente vantaggiosa per la crescita sostenuta del traffico crescita.
Nodi ad avvio rapido Provisioning dei nodi e pianificazione dei pod Riduce il tempo di avvio dei nodi a freddo in base al principio del best-effort utilizzando hardware pre-inizializzato. Fornito senza costi aggiuntivi.

Cluster Autopilot e carichi di lavoro Autopilot nei cluster standard.

Supporta le serie di macchine per uso generico e GPU idonee senza SSD locali o VM spot.

 Accelerare il provisioning dei nodi di base senza costi di configurazione o capacità inattiva.
Pod segnaposto a bassa priorità Provisioning dei nodi e pianificazione dei pod Pianificazione immediata dei pod dopo l'eliminazione dei pod segnaposto a priorità inferiore Pod.

Tariffe di calcolo standard per i nodi in esecuzione.

Richiede la gestione manuale di Deployment e PriorityClass.

 Cluster standard e Autopilot. Riservare capacità di riserva sui cluster che utilizzano la fatturazione basata sui pod o versioni precedenti alla 1.35.
Streaming di immagini Pull delle immagini container Consente l'avvio dei container senza attendere il download dell'intera immagine.

Fornito senza costi aggiuntivi.

Richiede Artifact Registry o repository Docker Hub idonei.

 Cluster Autopilot (abilitati per impostazione predefinita) e standard. Ridurre i tempi di pull delle immagini per le immagini container di grandi dimensioni.
Dischi di avvio secondari Pull delle immagini container Collega un Persistent Disk precompilato ai nuovi nodi in parallelo con il provisioning dei nodi. Viene addebitato il costo del Persistent Disk collegato a ogni nodo e dell'archiviazione delle immagini disco storage. Cluster standard e Autopilot. Precaricare immagini container di grandi dimensioni o set di dati statici come i pesi dei modelli di machine learning.
Snapshot dei pod Inizializzazione dell'applicazione Ripristina le nuove repliche dei pod direttamente da un checkpoint salvato della memoria del processo e dello stato del file system. Viene addebitato il costo dell'archiviazione degli snapshot in Cloud Storage.

Cluster standard e Autopilot che eseguono pod in GKE Sandbox.

Supporta i tipi di macchine CPU e GPU idonei (no TPU).

 Ignorare l'inizializzazione prolungata per i modelli di inferenza AI e le applicazioni con routine di avvio pesanti.
Boost della CPU all'avvio (anteprima) Inizializzazione dell'applicazione Aumenta temporaneamente le richieste e i limiti della CPU durante l'avvio del pod, quindi li ridimensiona in loco. Consuma temporaneamente la capacità della CPU del nodo aggiuntiva durante la finestra di avvio window. Cluster standard e Autopilot con scalabilità automatica pod verticale abilitata. Accelerare l'inizializzazione vincolata alla CPU per runtime come Java, Python o Node.js.

Scegliere una strategia in base alla fase di avvio dei pod

Le sezioni seguenti descrivono le opzioni disponibili per ogni fase del ciclo di vita di avvio dei pod.

Accelerare il provisioning dei nodi e la pianificazione dei pod

Quando i pod in attesa non possono essere inseriti nei nodi esistenti, l'attesa dell'avvio di un nuovo nodo è spesso il fattore che contribuisce maggiormente alla latenza di scalabilità. Puoi ridurre o eliminare questo ritardo utilizzando le seguenti strategie:

  • Utilizza i buffer di capacità per riservare in modo dichiarativo la capacità dei nodi di riserva:
    • Configura un buffer attivo (strategia buffer.x-k8s.io/active-capacity) per mantenere i nodi di cui è stato eseguito il provisioning in esecuzione e pronti a pianificare immediatamente i pod. I buffer attivi supportano i carichi di lavoro CPU, GPU e TPU.
    • Configura un buffer di standby (strategia buffer.gke.io/standby-capacity) per mantenere i nodi CPU di cui è stato eseguito il provisioning in uno stato sospeso. Quando i carichi di lavoro aumentano, GKE riprende i nodi di standby in circa 30-35 secondi, evitando il costo di calcolo completo dell'esecuzione delle VM inattive.
  • Affidati ai nodi ad avvio rapido per la pre-inizializzazione automatica dell'hardware con il principio del best-effort sui carichi di lavoro Autopilot e sulle serie di macchine GPU idonee. Quando GKE esegue il provisioning di nuovi nodi per un carico di lavoro idoneo, utilizza automaticamente i nodi ad avvio rapido. Sono inclusi i nodi creati per riempire un buffer di capacità su una ComputeClass personalizzata Autopilot compatibile.
  • Esegui il deployment di pod segnaposto a bassa priorità con PriorityClass Kubernetes se i carichi di lavoro utilizzano il modello di fatturazione basato sui pod Autopilot o vengono eseguiti su versioni di GKE precedenti alla 1.35. Per i cluster che utilizzano la fatturazione basata sui nodi nelle versioni di GKE supportate, preferisci i buffer di capacità dichiarativi perché non richiedono la gestione di deployment segnaposto o loop di eliminazione dei pod.

Accelerare i pull delle immagini container

Dopo che lo scheduler inserisce un pod su un nodo, il nodo deve eseguire il pull dell'immagine container prima di avviare il container. Puoi ridurre la latenza di pull delle immagini utilizzando le seguenti strategie:

  • Abilita lo streaming di immagini per consentire l'avvio dei container non appena i file richiesti vengono trasmessi in streaming sulla rete, mentre il resto dell'immagine viene scaricato in background. I cluster Autopilot abilitano lo streaming di immagini per impostazione predefinita per le immagini idonee in Artifact Registry.
  • Configura i dischi di avvio secondari per precaricare i livelli di base dei container di grandi dimensioni o i set di dati statici su un'immagine disco personalizzata. Quando GKE crea un nodo, collega un Persistent Disk di cui è stata creata un'istanza dall'immagine disco in parallelo con il provisioning dei nodi.
  • Esegui un DaemonSet per precaricare le immagini container nei buffer di standby durante la finestra di inizializzazione dei nodi (buffer.gke.io/standby-capacity-init-time annotazione). Prima che GKE sospenda un nodo di standby, il DaemonSet esegue il pull delle immagini dei carichi di lavoro sul disco di avvio del nodo in modo che le immagini siano già memorizzate nella cache quando il nodo viene ripreso.

Accelerare l'inizializzazione dell'applicazione

Anche dopo che un nodo è in esecuzione e l'immagine container è presente, le applicazioni possono impiegare molto tempo per caricare i framework, compilare il codice JIT (Just-In-Time) o caricare i pesi del modello in memoria. Puoi ridurre il tempo di inizializzazione utilizzando le seguenti strategie:

  • Configura gli snapshot dei pod per acquisire un checkpoint della memoria e dello stato del file system di un pod in esecuzione in GKE Sandbox. Quando il carico di lavoro viene scalato orizzontalmente, GKE ripristina le nuove repliche dallo snapshot in Cloud Storage in modo che il pod riprenda l'esecuzione dal punto in cui è stato creato lo snapshot anziché inizializzarsi da uno stato nuovo.
  • Configura il boost della CPU all'avvio su un VerticalPodAutoscaler per allocare CPU aggiuntiva a un pod durante l'ammissione e l'inizializzazione. Una volta che il pod raggiunge lo stato Ready e la durata del boost configurata termina, GKE riduce la richiesta di CPU del pod al livello di base in loco senza riavviare il container.

Combinare le strategie per l'ottimizzazione end-to-end

Poiché queste strategie operano in fasi diverse del ciclo di vita di avvio dei pod, puoi combinarle per ottimizzare il tempo di scalabilità end-to-end:

  • Combina un piccolo buffer di capacità attiva con un buffer di capacità di standby più grande. Durante un improvviso picco di traffico, il buffer attivo assorbe immediatamente il burst iniziale di pod. Nel frattempo, GKE riprende i nodi dal buffer di standby in circa 30-35 secondi per reintegrare il buffer attivo e gestire la crescita sostenuta. In background, il gestore della scalabilità automatica del cluster esegue il provisioning e sospende i nuovi nodi per riempire il buffer di standby.
  • Per i buffer di capacità di standby, abilita lo streaming di immagini o precarica le immagini container utilizzando un DaemonSet prima che il nodo venga sospeso in modo che il nodo non impieghi tempo a scaricare immagini container di grandi dimensioni quando viene ripreso.
  • Applica il boost della CPU all'avvio o gli snapshot dei pod sopra i buffer di capacità o i nodi ad avvio rapido in modo che, dopo che GKE pianifica un pod su un nodo di cui è stato eseguito il provisioning o la pre-inizializzazione, il pod eviti la limitazione della CPU durante l'avvio o venga ripristinato direttamente da uno snapshot salvato.

Per misurare l'effetto di una singola strategia o di una combinazione di strategie sui carichi di lavoro, visualizza i grafici Distribuzione della latenza di avvio dei pod e Latenza del primo stato Pronto dei pod in Cloud Monitoring e controlla i log della latenza di pianificazione in Cloud Logging. Per le istruzioni, consulta Monitorare le metriche della latenza di avvio.

Passaggi successivi