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 in 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 in 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 in standby riprendono rapidamente, fornendo una disponibilità di capacità più rapida rispetto ai nodi nuovi 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 dei carichi di lavoro:hai il controllo completo 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.
Consigliamo i buffer di capacità per i carichi di lavoro sensibili alla latenza che richiedono uno scale up rapido, come agenti AI, inferenza AI, applicazioni di vendita al dettaglio durante gli eventi di vendita o 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 tratta 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 di pod durante un evento di scale up.
Buffer in standby
Un buffer in standby fornisce nodi sospesi. La strategia in 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 standard di GKE 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 in 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 in standby per ospitare i carichi di lavoro, vengono applicate 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 criteri diversi:
- 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 vengono modificate in modo dinamico 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 tipo "standby-first" economicamente vantaggiosa: dai la priorità ai buffer in 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 VM nuove 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 in standby più grande per una configurazione economicamente vantaggiosa. GKE dà la priorità al riempimento del buffer attivo riprendendo i nodi dal buffer in standby (circa 30 secondi), mentre i nuovi nodi vengono sottoposti a provisioning in background per riempire il buffer in standby. Questa configurazione assorbe i picchi iniziali con la capacità attiva e supporta la crescita sostenuta utilizzando la capacità in 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 in standby possano riprendere.
- Dimensiona i buffer in standby per il carico sostenuto: definisci i buffer in 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 in 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 in 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 in 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 in standby vengono conteggiati ai fini delle quote di Compute Engine.
I buffer in standby presentano le seguenti limitazioni aggiuntive:
- Sono supportati solo nei cluster standard con il provisioning automatico dei nodi abilitato.
- I nodi con GPU o TPU collegate non sono supportati.
- Le SSD locali non sono supportate.
- Le chiavi di crittografia gestite dal cliente (CMEK) non sono supportate.
- I nodi Google Kubernetes Engine riservati non sono supportati.
- Devi conoscere le limitazioni relative alle operazioni di sospensione e ripresa di Compute Engine.
Di seguito sono riportate alcune limitazioni principali:
- 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 alla dimensione della memoria.
- La ripresa dipende dalla disponibilità delle risorse sottostanti necessarie per la ripresa.
Passaggi successivi
- Per scoprire come implementare un buffer di capacità, consulta Configurare i buffer di capacità.