Informazioni sui buffer di capacità

I buffer di capacità ti aiutano a ridurre la latenza di avvio dei pod per i carichi di lavoro di Google Kubernetes Engine (GKE) consentendoti di dichiarare in modo proattivo i livelli di buffer di capacità attivi o di standby nel cluster. Dichiarando la capacità di riserva in anticipo, puoi ottenere avvii dei carichi di lavoro più rapidi in modo economicamente vantaggioso.

Questo documento spiega come funzionano i buffer di capacità. Per scoprire come abilitare e utilizzare i buffer di capacità, consulta Configurare i buffer di capacità.

Quando utilizzare i buffer di capacità

Utilizza i buffer di capacità per le applicazioni sensibili alla latenza di avvio e che devono scalare rapidamente. Quando si verificano aumenti improvvisi del traffico, un buffer attivo fornisce capacità di cui è stato eseguito il provisioning in anticipo, progettata per la scalabilità a bassa latenza. Quando si verifica un aumento sostenuto del traffico, un buffer di standby fornisce la pianificazione dei pod a un costo più conveniente rispetto al provisioning anticipato.

I buffer di capacità offrono i seguenti vantaggi:

  • Riduci al minimo la latenza di scalabilità: i buffer attivi forniscono nodi in esecuzione, che contribuiscono a ridurre al minimo la latenza. I buffer di standby riprendono rapidamente, fornendo una disponibilità di capacità più rapida rispetto ai nuovi nodi a un costo inferiore rispetto ai buffer attivi.
  • Provisioning eccessivo economicamente vantaggioso: i buffer di capacità ti aiutano a mantenere una rete di sicurezza. Per i carichi di lavoro su larga scala, questo approccio è spesso più conveniente rispetto ad altri metodi di provisioning eccessivo (ad esempio, la riduzione dei target di utilizzo di HorizontalPodAutoscaler (HPA)), che possono aumentare la capacità inattiva in modo lineare man mano che il cluster cresce.
  • Soddisfa i requisiti del carico di lavoro:hai il pieno controllo sulla configurazione del buffer di capacità. Le opzioni includono l'incorporamento di daemonset personalizzati per precaricare le immagini, la regolazione del tempo di avvio e il controllo delle dimensioni dei buffer in base alle tue esigenze.

Ti consigliamo di utilizzare i buffer di capacità per i carichi di lavoro sensibili alla latenza che richiedono uno scale up rapido, come gli agenti AI, l'inferenza AI, le applicazioni di vendita al dettaglio durante gli eventi di vendita o i server di gioco durante i picchi di attività dei giocatori.

Come funzionano i buffer di capacità

Implementa un buffer di capacità utilizzando una risorsa personalizzata CapacityBuffer di Kubernetes per definire un buffer di capacità di riserva. Il gestore della scalabilità automatica dei cluster GKE monitora le risorse CapacityBuffer e le considera come domanda in attesa per garantire la disponibilità della capacità di riserva. Se il cluster non ha capacità sufficiente per soddisfare le richieste di risorse definite nel buffer, il gestore della scalabilità automatica dei cluster esegue il provisioning di nodi aggiuntivi.

Quando un carico di lavoro ad alta priorità esegue lo scale up, GKE pianifica immediatamente il carico di lavoro sulla capacità disponibile nel buffer. Questa pianificazione immediata si applica al numero di repliche o alla quantità di risorse riservate nel buffer, evitando il ritardo tipico associato al provisioning dei nodi. Quando un carico di lavoro utilizza un'unità buffer, il gestore della scalabilità automatica dei cluster esegue il provisioning di un nuovo nodo per riempire il buffer.

Strategie dei buffer di capacità

Puoi configurare i buffer di capacità utilizzando diverse strategie di provisioning in base ai tuoi requisiti di latenza e costi.

Buffer attivo

Un buffer attivo fornisce nodi in esecuzione per la scalabilità a bassa latenza dei carichi di lavoro che rientrano nella capacità riservata. Poiché i nodi sono già in esecuzione, forniscono una latenza minima per la richiesta dei pod durante un evento di scale up.

Buffer di standby

Un buffer di standby fornisce nodi sospesi. La strategia di standby è più conveniente rispetto alla strategia attiva, ma introduce un breve ritardo per riprendere il nodo prima che accetti i carichi di lavoro.

Costi e prezzi

La fatturazione dei buffer di capacità varia a seconda del tipo di buffer:

  • Buffer attivi: ti vengono addebitate le tariffe di calcolo GKE standard per le VM in esecuzione che GKE gestisce per fungere da capacità di buffer attiva. In Autopilot, le tariffe di fatturazione standard basate sui pod si applicano ai pod in esecuzione.
  • Buffer di standby: mentre le istanze VM sono sospese, non paghi i costi di calcolo (CPU o memoria). Ti vengono addebitati costi di archiviazione minori (ad esempio, dischi di avvio VM) e costi per le risorse associate, come gli indirizzi IP esterni statici. Quando GKE riprende le VM di standby per ospitare i carichi di lavoro, si applicano le tariffe di fatturazione standard basate sul calcolo o sui pod.

CRD CapacityBuffer

Per configurare un buffer di capacità, crea una definizione di risorsa personalizzata (CRD) CapacityBuffer. Puoi configurare il buffer di capacità in base a diversi criteri:

  • Repliche fisse: specifica un numero fisso di pod buffer da creare in base a lle richieste di risorse di un modello di pod di riferimento. Questa configurazione è il modo più semplice per creare un buffer di dimensioni note.
  • Limiti delle risorse: specifica la quantità totale di CPU e memoria che il buffer deve riservare. Il controller calcola il numero di pod buffer da creare in base alle richieste di risorse di un modello di pod di riferimento.
  • Basato sulla percentuale: definisci le dimensioni del buffer come percentuale di un oggetto scalabile esistente che definisce una sotto-risorsa di scalabilità (ad esempio, un deployment, uno StatefulSet, un ReplicaSet o un job). Le dimensioni del buffer si regolano dinamicamente man mano che il carico di lavoro di riferimento viene scalato. I buffer di capacità basati sulla percentuale sono solo supportati per gli oggetti che implementano la sotto-risorsa di scalabilità di Kubernetes.

Per ulteriori informazioni, consulta la documentazione di riferimento della CRD CapacityBuffer.

Best practice

Per ottimizzare l'efficienza in termini di costi e la reattività durante la configurazione dei buffer di capacità, utilizza i seguenti suggerimenti:

  • Utilizza una strategia di standby-first economicamente vantaggiosa: dai la priorità ai buffer di standby se i tuoi carichi di lavoro possono tollerare un breve ritardo di scale up di circa 30 secondi. Questa strategia evita gli avvii a freddo dei nodi delle nuove VM senza dover sostenere il costo totale delle VM attive.
  • Utilizza i buffer attivi per i carichi di lavoro sensibili alla latenza: utilizza i buffer attivi per i carichi di lavoro che non possono tollerare i tempi di ripresa dei nodi quando il tempo di pianificazione dei pod deve essere il più basso possibile.
  • Utilizza una strategia ibrida per bilanciare prestazioni e costi: combina un piccolo buffer attivo con un buffer di standby più grande per una configurazione economicamente vantaggiosa. GKE dà la priorità al riempimento del buffer attivo riprendendo i nodi dal buffer di standby (impiegando circa 30 secondi), mentre i nuovi nodi vengono sottoposti a provisioning in background per riempire il buffer di standby. Questa configurazione assorbe i picchi iniziali con la capacità attiva e supporta la crescita sostenuta utilizzando la capacità di standby a costi inferiori.
  • Dimensiona i buffer attivi per i burst iniziali: definisci le dimensioni del buffer attivo in modo da coprire i picchi iniziali improvvisi di repliche che prevedi di incontrare, prima che i nodi del buffer di standby possano riprendere.
  • Dimensiona i buffer di standby per il carico sostenuto: definisci i buffer di standby che sono sufficienti a coprire il carico esteso che prevedi di incontrare, in modo che i buffer possano essere riempiti in background da un avvio a freddo. Un buffer di standby di dimensioni sufficienti può ridurre la latenza massima di pianificazione dei pod al tempo necessario per riprendere un nodo, ovvero circa 30 secondi. Quando il buffer di capacità inizia a essere utilizzato e viene riempito, i nuovi nodi del buffer passano a uno stato attivo prima della sospensione. Questa strategia contribuisce ad aumentare la capacità attiva durante un carico prolungato.
  • Utilizza il simulatore di buffer: sperimenta con diverse dimensioni dei buffer attivi e di standby per ottenere il risultato migliore per il tuo carico di lavoro specifico. Esegui simulazioni del comportamento di scalabilità dei carichi di lavoro utilizzando il simulatore di buffer GKE open source all'indirizzo https://github.com/gke-labs/buffers-simulator per ottimizzare le regole di dimensionamento dei buffer e raggiungere i target di rendimento.

Requisiti e limitazioni

I buffer di capacità presentano i seguenti requisiti e limitazioni:

  • I buffer di capacità sono disponibili per i cluster GKE che eseguono la versione 1.35.2-gke.1842000 o successive per i buffer attivi e la versione 1.36.0-gke.2253000 per i buffer di standby.
  • I buffer di capacità supportano solo i carichi di lavoro che utilizzano un modello di fatturazione basato sui nodi per i pool di nodi standard e i pool di nodi Autopilot che selezionano hardware specifici. I buffer di capacità non supportano i carichi di lavoro che utilizzano il modello di fatturazione basato sui pod.
  • Nei cluster standard, ti consigliamo di abilitare il provisioning automatico dei nodi. Il provisioning automatico dei nodi consente al gestore della scalabilità automatica dei cluster di creare nuovi pool di nodi in base alle richieste di risorse in CapacityBuffer. Se non abiliti il provisioning automatico dei nodi, il gestore della scalabilità automatica dei cluster esegue solo lo scale up dei pool di nodi esistenti.
  • Sia i buffer di capacità attivi che quelli di standby vengono conteggiati ai fini delle quote di Compute Engine.
  • Se la dipendenza dalla configurazione di CapacityBuffer (ad esempio, un PodTemplate) seleziona un ComputeClass personalizzato, la dipendenza deve definire eventuali tolleranze, selettori di nodi o classi di runtime richieste per la pianificazione sui nodi di cui è stato eseguito il provisioning (ad esempio, requisiti per GKE Sandbox). Per le istruzioni, consulta la documentazione di ComputeClass personalizzata .

I buffer di standby presentano le seguenti limitazioni aggiuntive:

  • Sono supportati nei cluster standard con il provisioning automatico dei nodi abilitato.
  • Sono supportati nei cluster Autopilot che eseguono la versione 1.36.0-gke.2853000 o successive.
  • I nodi con GPU o TPU collegate non sono supportati.
  • Le SSD locali non sono supportate.
  • I nodi di Google Kubernetes Engine riservati non sono supportati.
  • Devi conoscere le limitazioni relative alle operazioni di sospensione e ripresa di Compute Engine. Alcune limitazioni chiave includono le seguenti:
    • I nodi con dischi protetti da chiavi di crittografia fornite dal cliente (CSEK) non sono supportati.
    • I nodi con più di 208 GB di memoria non sono supportati.
    • Le istanze Bare Metal non sono supportate.
    • Il sistema operativo del nodo deve supportare gli indicatori di sospensione ACPI S3.
    • La durata del processo di sospensione è proporzionale alle dimensioni della memoria.
    • La ripresa dipende dalla disponibilità delle risorse sottostanti necessarie per la ripresa.

Passaggi successivi