Informazioni sui buffer di capacità

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

Questo documento spiega come funzionano i buffer di capacità. Per scoprire come attivare e utilizzare i buffer di capacità, consulta Configura 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 una capacità pre-provisionata progettata per la scalabilità a bassa latenza. Quando si verifica un aumento prolungato del traffico, un buffer di standby fornisce la pianificazione dei pod a un costo più conveniente rispetto al pre-provisioning.

I buffer di capacità offrono i seguenti vantaggi:

  • Riduci al minimo la latenza di scalabilità: i buffer attivi forniscono nodi in esecuzione, il che contribuisce a ridurre al minimo la latenza. I buffer in standby riprendono rapidamente, fornendo una disponibilità della capacità più rapida rispetto ai nuovi nodi a un costo inferiore rispetto ai buffer attivi.
  • Overprovisioning conveniente: i buffer di capacità ti aiutano a mantenere una rete di sicurezza. Per i workload su larga scala, questo approccio è spesso più conveniente rispetto ad altri metodi di overprovisioning, come 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 sulla 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 i buffer di capacità per i workload 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à su Play.

Come funzionano i buffer di capacità

Implementa un buffer di capacità utilizzando una risorsa personalizzata Kubernetes CapacityBuffer 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 che sia disponibile capacità di riserva. Se il cluster non dispone di 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 esegue lo scale up, GKE pianifica i pod in attesa sulla capacità disponibile nel seguente ordine di priorità:

  1. Esecuzione di nodi in un buffer attivo
  2. Nodi in esecuzione in un buffer di standby che non sono ancora stati sospesi
  3. Nodi sospesi in un buffer di standby
  4. Nodi di cui è stato appena eseguito il provisioning

Per pianificare i pod in attesa il più rapidamente possibile, GKE utilizza la capacità di buffer disponibile prima di eseguire il provisioning di nuovi nodi. Questa priorità viene applicata anche se una regola con priorità più alta in una ComputeClass personalizzata eseguirebbe il provisioning di un nuovo nodo.

La capacità del buffer non è limitata al workload a cui si fa riferimento nel campo scalableRef. Qualsiasi pod in attesa i cui vincoli di pianificazione, come selettori di nodi, tolleranze e richieste di risorse, corrispondono alla configurazione del nodo buffer può rivendicare questa capacità. Per prenotare un buffer di capacità per un workload specifico, configura la separazione dei workload aggiungendo tolleranze e selettori di nodi (o affinità dei nodi) corrispondenti sia al workload sia al buffer di capacità.

Quando un workload consuma capacità da un buffer attivo, il gestore della scalabilità automatica dei cluster reintegra il buffer attivo riprendendo un nodo da un buffer di standby compatibile, se esistente, o eseguendo il provisioning di un nuovo nodo. Quando un workload o un buffer attivo consuma un nodo da un buffer di standby, il gestore della scalabilità automatica dei cluster riempie il buffer di standby eseguendo il provisioning e la sospensione di un nuovo nodo. Quando il workload fa lo scale down e i nodi diventano sottoutilizzati, il gestore della scalabilità automatica dei cluster elimina i nodi in esecuzione in eccesso dopo la finestra di stabilizzazione dello scale down, anziché sospenderli nuovamente nel buffer di standby. Per ripristinare il buffer di standby, GKE esegue il provisioning e sospende i nuovi nodi separatamente.

Strategie per il buffer di capacità

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

Buffer attivo

Un buffer attivo fornisce nodi in esecuzione per la scalabilità a bassa latenza dei workload che rientrano nella capacità prenotata. Poiché i nodi sono già in esecuzione, offrono una latenza minima per la richiesta di 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 workload.

Costi e prezzi

I buffer di capacità vengono forniti senza costi aggiuntivi oltre ai costi di computing standard basati sui nodi, che si applicano ai node pool Standard e ai workload Autopilot che selezionano hardware specifico. I buffer di capacità non supportano il modello di fatturazione basato su pod.

La fatturazione per i nodi sottostanti varia a seconda del tipo di buffer:

  • Buffer attivi: ti vengono addebitate le tariffe di computing standard basate sui nodi per le VM in esecuzione che GKE gestisce per fungere da capacità di buffer attiva.
  • Buffer di standby: mentre le istanze VM sono sospese, non paghi i costi di computing (CPU o memoria). Ti vengono addebitati costi di archiviazione inferiori (ad esempio, dischi di avvio delle VM e stato della memoria archiviata) e costi per le risorse associate, come gli indirizzi IP esterni statici. Quando GKE riprende le VM in standby per ospitare i workload, si applicano le tariffe di computing standard basate sui nodi. Per ulteriori informazioni, consulta la sezione Prezzi delle istanze sospese.

CRD CapacityBuffer

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

  • Repliche fisse: specifica un numero fisso di pod buffer da creare in base alle richieste di risorse di un template 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 prenotare. Il controller calcola il numero di pod buffer da creare in base alle richieste di risorse di un template di pod di riferimento.
  • Basata su percentuale: definisci la dimensione del buffer come percentuale di un oggetto scalabile esistente che definisce una sottorisorsa di scalabilità (ad esempio un deployment, un StatefulSet, un ReplicaSet o un job). La dimensione del buffer viene regolata dinamicamente in base alla scalabilità del workload di riferimento. I buffer di capacità basati su percentuale sono supportati solo per gli oggetti che implementano la sottorisorsa di scalabilità di Kubernetes.

Puoi combinare queste opzioni, ad esempio impostando sia replicas che percentage in modo che GKE utilizzi il valore più grande come soglia minima e impostando limits come limite superiore.

Per saperne di più, 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 ottimizzata per i costi: dai la priorità ai buffer di standby se i tuoi workload possono tollerare un breve ritardo di scale up di circa 30 secondi. Questa strategia evita gli avvii a freddo dei nodi di nuove VM senza dover sostenere l'intero costo delle VM attive.
  • Utilizza i buffer attivi per i workload sensibili alla latenza: utilizza i buffer attivi per i workload 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 conveniente. GKE dà la priorità al riempimento del buffer attivo riprendendo i nodi dal buffer di standby (operazione che richiede circa 30 secondi), mentre viene eseguito il provisioning di nuovi nodi 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 costo inferiore.
  • Dimensiona i buffer attivi per i burst iniziali: definisci le dimensioni del buffer attivo per coprire i picchi improvvisi iniziali di replica che prevedi di riscontrare, prima che i nodi del buffer in standby possano riprendere.
  • Dimensiona i buffer di standby per un carico prolungato: definisci buffer di standby sufficienti per coprire il carico esteso che prevedi di incontrare, in modo che i buffer possano essere ricaricati 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 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 in standby per ottenere il risultato migliore per il tuo workload specifico. Esegui simulazioni del comportamento di scalabilità dei workload 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.
  • Riduci la latenza di avvio a freddo durante la scalabilità dei workload da zero: abbina i workload che scalano da e verso zero utilizzando l'HPA (minReplicas: 0) con i buffer di capacità. Quando la domanda aumenta e il workload viene scalato da zero, GKE pianifica immediatamente i pod sui nodi buffer preriscaldati, anziché attendere il provisioning di nuovi nodi di computing.
  • Prendi in considerazione il profilo di scalabilità automatica optimize-utilization sui cluster Standard: poiché i buffer di capacità mantengono già un margine di sicurezza, puoi configurare il profilo di scalabilità automatica optimize-utilization (--autoscaling-profile=optimize-utilization) in modo che il gestore della scalabilità automatica dei cluster faccia lo scale down più rapidamente dei nodi sottoutilizzati dopo un calo della domanda. Questo profilo raggruppa anche i pod in modo più stretto sui nodi, quindi valuta se un bin packing più stretto soddisfa i requisiti di disponibilità del workload prima di attivarlo.

Calcola la dimensione del buffer

Quando combini un buffer attivo con un buffer in standby, puoi stimare il numero di repliche del buffer o di pod del buffer simulati necessari per assorbire un picco di traffico. Calcola questa stima utilizzando la frequenza di scale up prevista in pod al secondo, la latenza di ripresa dei nodi in standby e la latenza di creazione dei nodi cold. Queste latenze variano in base alla serie di macchine VM e alla configurazione dei nodi. Ad esempio, la latenza di ripresa del nodo in standby è in genere compresa tra 30 e 35 secondi, mentre la latenza di creazione di un nuovo nodo è in genere compresa tra 60 e 120 secondi, a seconda della serie di macchine. Per misurare le latenze effettive del tuo cluster, consulta Monitora le metriche di latenza di avvio.

  1. Calcola la dimensione del buffer attivo per coprire i pod creati durante il ripristino dei nodi in standby:

    \[ \text{Active buffer replicas} = \text{Expected scale-up rate} \times \text{Standby node resume latency} \]

  2. Calcola la dimensione del buffer di standby per coprire i pod rimanenti creati mentre i nuovi nodi cold completano il provisioning:

    \[ \text{Standby buffer replicas} = (\text{Expected scale-up rate} \times \text{Cold node creation latency}) - \text{Active buffer replicas} \]

Ad esempio, se il tuo workload fa lo scale up di 2 pod al secondo, i nodi in standby impiegano 30 secondi per riprendere l'esecuzione e i nuovi nodi cold impiegano 90 secondi per il provisioning:

  • Il buffer attivo ha bisogno di \( 2 \times 30 = 60 \) repliche per assorbire i primi 30 secondi del picco.
  • Il buffer di standby richiede \( (2 \times 90) - 60 = 120 \) repliche per coprire i restanti 60 secondi mentre il gestore della scalabilità automatica dei cluster esegue il provisioning di nuovi nodi cold in background per riempire i buffer. Se il picco continua oltre i 90 secondi alla stessa velocità, i nodi reintegrati sono pronti per gestire i pod in entrata senza tempi di attesa.

Per testare queste stime rispetto ai pattern di scalabilità del workload, esegui simulazioni con il simulatore di buffer GKE.

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 node pool Standard e i node pool Autopilot che selezionano hardware specifico. I buffer di capacità non supportano i workload che utilizzano il modello di fatturazione basato su pod.
  • Sui cluster Standard, ti consigliamo di attivare la creazione automatica dei node pool. La creazione automatica dei node pool consente al gestore della scalabilità automatica dei cluster di creare nuovi node pool in base alle richieste di risorse nel CapacityBuffer. Se non attivi la creazione automatica dei pool di nodi, il gestore della scalabilità automatica dei cluster scala solo i node pool esistenti.
  • I buffer di capacità attivi e in standby consumano le quote in modo diverso:
    • I nodi in esecuzione in un buffer attivo vengono conteggiati ai fini delle quote di Compute Engine per vCPU, memoria, disco e indirizzi IP.
    • I nodi sospesi in un buffer di standby non vengono conteggiati ai fini delle quote di vCPU o memoria di Compute Engine mentre sono sospesi. Tuttavia, continuano a consumare quote di indirizzi IP e quote di disco, inclusa la quota di Persistent disk standard (GB) utilizzata per archiviare la memoria della VM sospesa.
    • In Kubernetes, sia le unità buffer di standby attive che quelle sospese vengono conteggiate ai fini delle quote delle risorse Kubernetes nel tuo spazio dei nomi, come se i pod buffer fossero in esecuzione.
  • Se la dipendenza della configurazione di CapacityBuffer (ad esempio un PodTemplate) seleziona una ComputeClass personalizzata, 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, i requisiti per GKE Sandbox). Per le istruzioni, consulta la documentazione relativa alla classe ComputeClass personalizzata.

I buffer di standby presentano le seguenti limitazioni aggiuntive:

  • Sono supportati sui cluster Standard con la creazione automatica dei node pool abilitata.
  • 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 unità SSD locali non sono supportate.
  • Sebbene i buffer di standby supportino le chiavi di crittografia gestite dal cliente (CMEK) per lo spazio di archiviazione del nodo, la memoria del nodo viene criptata utilizzando Google-owned and Google-managed encryption keys durante la sospensione.
  • I nodi Confidential Google Kubernetes Engine non sono supportati.
  • I buffer di standby supportano solo le immagini dei nodi Container-Optimized OS e Ubuntu di GKE. I nodi Windows Server non sono supportati. Se utilizzi un sistema operativo dei nodi personalizzato, devi assicurarti che supporti le operazioni di sospensione e ripresa di Compute Engine.
  • Dovresti avere familiarità con le limitazioni relative alle operazioni di sospensione e ripresa di Compute Engine. Alcune limitazioni chiave includono:
    • 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.

Passaggi successivi