Informazioni sui buffer di capacità

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

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

Quando utilizzare i buffer di capacità

Utilizza 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à pre-provisioning progettata per lo scaling a bassa latenza. Quando si verifica un aumento sostenuto del traffico, un buffer di standby consente la pianificazione dei pod a un costo più conveniente rispetto al pre-provisioning.

I buffer di capacità offrono i seguenti vantaggi:

  • Ridurre al minimo la latenza di scalabilità: i buffer attivi forniscono nodi in esecuzione, il che contribuisce a ridurre al minimo la latenza. I buffer di standby riprendono rapidamente, fornendo una disponibilità di capacità più rapida rispetto ai nodi nuovi a un costo inferiore rispetto ai buffer attivi.
  • Overprovisioning conveniente: 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 overprovisioning, ad esempio l'abbassamento dei target di utilizzo del gestore della scalabilità automatica orizzontale dei pod (HPA), che può aumentare la capacità inattiva in modo lineare man mano che il cluster cresce.
  • Soddisfa i requisiti del workload:hai il pieno controllo della configurazione del buffer di capacità. Le opzioni includono l'incorporamento di daemonset personalizzati per precaricare le immagini, l'ottimizzazione del tempo di avvio e il controllo delle dimensioni del buffer in base alle tue esigenze.

Consigliamo buffer di capacità per i workload sensibili alla latenza che richiedono uno scale up rapido, come agenti AI, inferenza AI, applicazioni di vendita al dettaglio durante 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. Lo strumento di scalabilità automatica del cluster GKE monitora le risorse CapacityBuffer e le considera come domanda in attesa per garantire che sia disponibile capacità di riserva. Se il cluster non ha capacità sufficiente per soddisfare le richieste di risorse definite nel buffer, il gestore della scalabilità automatica del cluster esegue il provisioning di nodi aggiuntivi.

Quando un workload ad alta priorità viene scalato, GKE lo pianifica immediatamente 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 del cluster esegue il provisioning di un nuovo nodo per riempire il buffer.

Strategie di buffer della 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 lo scaling a bassa latenza dei workload che rientrano nella capacità riservata. Poiché i nodi sono già in esecuzione, forniscono una latenza minima per la rivendicazione dei pod durante un evento di scale up.

Buffer di standby

Un buffer di riserva 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 di GKE standard per le VM in esecuzione che GKE gestisce per fungere da capacità di buffer attiva. Su Autopilot, vengono applicate le tariffe standard di fatturazione basata sui pod 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 minimi (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, vengono applicate le tariffe di fatturazione standard per il calcolo o basate sui pod.

CRD CapacityBuffer

Per configurare un buffer di capacità, crea una CustomResourceDefinition (CRD) CapacityBuffer. Puoi configurare il buffer di capacità in modo che soddisfi criteri diversi:

  • Replica fisse: specifica un numero fisso di pod buffer da creare in base alle 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 a cui viene fatto riferimento.
  • Basato sulla percentuale: definisci le dimensioni del buffer come percentuale di un oggetto scalabile esistente che definisce una risorsa secondaria di scalabilità (ad esempio Deployment, StatefulSet, ReplicaSet o Job). Le dimensioni del buffer vengono regolate dinamicamente man mano che viene scalato il workload di riferimento. I buffer di capacità basati sulla percentuale sono supportati solo per gli oggetti che implementano la risorsa secondaria di scalabilità di Kubernetes.

Per saperne di più, consulta la documentazione di riferimento 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 priorità allo standby ottimale in termini di costi: dai la priorità ai buffer di standby se i tuoi workload possono tollerare un breve ritardo di scalabilità verticale di circa 30 secondi. Questa strategia evita l'avvio di nodi freddi di VM nuove senza dover sostenere il costo totale delle VM attive.
  • Utilizza buffer attivi per i workload sensibili alla latenza: utilizza buffer attivi per i workload che non possono tollerare i tempi di ripristino dei nodi quando il tempo di pianificazione dei pod deve essere il più basso possibile.
  • Utilizza una strategia ibrida per bilanciare rendimento e costi: combina un piccolo buffer attivo con un buffer di standby più grande per una configurazione conveniente. GKE dà la priorità al riempimento del buffer attivo ripristinando i nodi dal buffer di standby (operazione che richiede circa 30 secondi), mentre i nuovi nodi vengono provisionati in background per riempire il buffer di standby. Questa configurazione assorbe i picchi iniziali con la capacità attiva e si adatta alla crescita sostenuta utilizzando la capacità di standby a costi inferiori.
  • Dimensiona i buffer attivi per i burst iniziali: definisci le dimensioni del buffer attivo per coprire i picchi improvvisi iniziali delle 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 buffer di standby 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 ricaricato, i nuovi nodi buffer passano a uno stato attivo prima della sospensione. Questa strategia aiuta ad aumentare la capacità attiva durante un carico prolungato.
  • Utilizza il simulatore di buffer: sperimenta con diverse dimensioni del buffer attivo e di standby per ottenere il risultato migliore per il tuo workload specifico. Esegui simulazioni del comportamento di scalabilità del carico 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 del buffer e raggiungere i tuoi target di rendimento.
  • Ridurre la latenza di avvio a freddo durante lo scaling dei workload da zero: accoppia i workload che vengono scalati a zero e da zero utilizzando HPA (minReplicas: 0) con buffer di capacità. Quando la domanda aumenta e il workload viene scalato da zero, GKE pianifica immediatamente i pod sui nodi buffer pre-riscaldati anziché attendere il provisioning di nuovi nodi di calcolo.

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 workload 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 su pod.
  • Nei cluster Standard, ti consigliamo di attivare il provisioning automatico dei nodi. Il provisioning automatico dei nodi consente al gestore della scalabilità automatica dei cluster di creare nuovi node pool in base alle richieste di risorse in CapacityBuffer. Se non abiliti il provisioning automatico dei nodi, lo scalatore automatico del cluster esegue solo lo scale up dei node pool esistenti.
  • I buffer di capacità attivi e di standby vengono conteggiati ai fini delle quote di Compute Engine.
  • Se la dipendenza di configurazione CapacityBuffer (ad esempio, un PodTemplate) seleziona una ComputeClass personalizzata, la dipendenza deve definire eventuali tolleranze, selettori di nodi o classi di runtime necessarie per la pianificazione sui nodi di cui è stato eseguito il provisioning (ad esempio, requisiti per GKE Sandbox). Per istruzioni, consulta la documentazione personalizzata di ComputeClass.

I buffer di standby presentano le seguenti limitazioni aggiuntive:

  • Sono supportati nei cluster Standard con il provisioning automatico dei nodi abilitato.
  • Sono supportati sui 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 Google Kubernetes Engine confidenziali non sono supportati.
  • Devi conoscere i limiti relativi 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 della procedura di sospensione è proporzionale alla dimensione della memoria.
    • La ripresa dipende dalla disponibilità delle risorse sottostanti necessarie per la ripresa.

Passaggi successivi