Questa pagina mostra come configurare i pod in modo che esplodano nella capacità non utilizzata disponibile sui nodi Google Kubernetes Engine (GKE).
Che cos'è il bursting?
Bursting descrive l'azione dei pod temporaneamente utilizzando più capacità di calcolo sul nodo rispetto a quanto richiesto in origine.
Kubernetes consente di richiedere capacità specifiche di risorse come CPU o memoria per i tuoi pod. Imposti queste richieste nel manifest del pod. Lo scheduler Kubernetes posiziona i pod su nodi con capacità sufficiente per soddisfare queste richieste di risorse.
Alcuni carichi di lavoro non utilizzano il 100% delle risorse richieste per l'intera esecuzione nel tempo. Ad esempio, un carico di lavoro che consuma CPU extra durante il periodo di avvio potrebbe non richiedere la stessa quantità di risorse per le normali operazioni. In queste in situazioni simili, puoi impostare i limiti delle risorse per il carico di lavoro su un valore più alto rispetto alle richieste di risorse o lasciare i limiti non impostati. GKE consente al carico di lavoro di utilizzare temporaneamente più risorse di quelle specificate nelle richieste, se questa capacità è disponibile.
Per saperne di più su come funziona questo processo in GKE, consulta Capacità massima in GKE in questa pagina.
Vantaggi dell'esplosione dei pod
Il bursting è utile quando i pod hanno bisogno solo di risorse aggiuntive per brevi di tempo per far fronte ai picchi di utilizzo delle risorse. Scenari di esempio include:
- Hai gruppi di carichi di lavoro che sono spesso inattivi e inviano un piccolo numero al secondo, ma occasionalmente si verificano picchi di traffico e usufruiscono di risorse aggiuntive per elaborare queste richieste.
- I carichi di lavoro richiedono più risorse durante l'avvio rispetto alle normali operazioni.
- Vuoi massimizzare l'utilizzo della capacità di calcolo di cui esegui il provisioning.
Il bursting ti consente di richiedere solo le risorse di cui il tuo pod ha bisogno per per la maggior parte del suo runtime, garantendo al contempo che il pod possa consumare se necessario. I vantaggi del bursting includono quanto segue:
- Costi di gestione inferiori: non è necessario richiedere il picco previsto del consumo di risorse del carico di lavoro. Le tue richieste possono riguardare valori in stato stabile. In Autopilot, paghi la somma del tuo pod di risorse, con costi di gestione inferiori.
- Utilizzo più efficiente delle risorse: eviti la capacità di calcolo inutilizzata perché i pod utilizzano la capacità inutilizzata. È più probabile che i tuoi carichi di lavoro utilizzino tutte le risorse a pagamento.
- Miglioramento delle prestazioni: i pod possono utilizzare risorse aggiuntive in base alle esigenze per ridurre il tempo di elaborazione delle richieste in arrivo o per l'avvio più rapido durante gli eventi di scale up.
Quando non usare la funzionalità di bursting
Kubernetes assegna la classe Burstable
Quality of Service (QoS) ai pod che
e specificare limiti di risorse
più elevati rispetto alle rispettive richieste. Burstable
pod QoS sono
di essere rimosso quando Kubernetes deve recuperare risorse sul
nodo. Per ulteriori informazioni, consulta la classe QoS burstable nella documentazione di Kubernetes.
Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:
- Attiva l'API Google Kubernetes Engine. Attiva l'API Google Kubernetes Engine
- Se vuoi utilizzare Google Cloud CLI per questa attività,
install e poi
inizializzare
con gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo
gcloud components update
.
- Assicurati che sia in esecuzione un cluster GKE Autopilot versione 1.30.2-gke.1394000 o successiva o qualsiasi versione di un nel cluster GKE Standard. Per creare un nuovo cluster, consulta Creare un cluster Autopilot.
Disponibilità di bursting in GKE
I carichi di lavoro possono aumentare nelle seguenti situazioni:
Disponibilità per picchi di domanda | |
---|---|
Modalità GKE Autopilot | Pod che utilizzano la classe di computing Performance o l'Accelerator computing può eseguire burst in qualsiasi versione GKE che supporti di quella classe di computing. In qualsiasi altra classe di computing e per i pod che non specificano una classe il bursting è disponibile solo se il cluster soddisfa entrambe le le seguenti condizioni:
Questa limitazione esiste perché, nei cluster Autopilot, il bursting richiede cgroup v2. cgroup v2 è disponibile solo nei cluster che sono stati creati originariamente con la versione 1.26 e successive. |
Modalità GKE Standard | I pod possono eseguire il burst in qualsiasi versione di GKE. |
I cluster Autopilot creati in origine con una versione precedente alla 1.26 e di cui è stato successivamente eseguito l'upgrade alla versione 1.29.2-gke.1060000 e successive non supportano il bursting. Per verificare la versione originale del cluster, esegui questo comando:
gcloud container clusters describe CLUSTER_NAME \
--location=LOCATION \
--format="value(initialClusterVersion)"
L'output deve essere GKE 1.26 o versioni successive.
Limitazioni
- I carichi di lavoro Autopilot possono utilizzare il picco solo per le richieste di CPU e memoria.
Quando esegui l'upgrade di un cluster Autopilot a una versione supportata, GKE esegue l'upgrade dei nodi worker in modo che corrispondano al piano di controllo la versione nel tempo. Per attivare l'esplosione è necessario riavviare il piano di controllo, e questo deve avvenire dopo che tutti i nodi eseguono una versione supportata. Il piano di controllo si riavvia automaticamente circa una volta alla settimana durante operazioni come la scalabilità, gli upgrade o la manutenzione.
Per attivare manualmente il riavvio di un piano di controllo:
Controlla se tutti i nodi eseguono la versione 1.30.2-gke.1394000 o successiva:
kubectl get nodes
L'output è simile al seguente:
NAME STATUS ROLES AGE VERSION gk3-ap-cluster-1-default-pool-18092e49-mllk Ready <none> 4m26s v1.30.2-gke.1349000
Tutti i nodi nell'output devono mostrare la versione richiesta o una successiva.
Avvia manualmente un upgrade del piano di controllo alla stessa versione già in uso dal cluster. Per istruzioni, vedi Upgrade manuale del piano di controllo.
Connettiti al cluster
Esegui questo comando:
gcloud container clusters get-credentials CLUSTER_NAME \
--location=LOCATION
Sostituisci quanto segue:
CLUSTER_NAME
: il nome del cluster esistente.LOCATION
: la posizione del cluster.
Esegui il deployment di un carico di lavoro espandibile
Salva il seguente manifest come
burstable-deployment.yaml
:apiVersion: apps/v1 kind: Deployment metadata: name: helloweb labels: app: hello spec: selector: matchLabels: app: hello tier: web template: metadata: labels: app: hello tier: web spec: containers: - name: hello-app image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 ports: - containerPort: 8080 resources: requests: cpu: 250m limits: cpu: 350m
Questo manifest contiene i seguenti campi per attivare l'esplosione:
resources.requests
: le risorse necessarie per il container personalizzata. Imposta questo valore sulla capacità necessaria al container in stato stabile.resources.limits
: la capacità massima di risorse che il contenitore può utilizzare. L'impostazione di limiti superiori alle richieste consente ai pod di eseguire il burst fino al il limite specificato, se questa capacità è disponibile sul nodo. Se ometti questo campo, i pod possono eseguire burst fino alla disponibilità di archiviazione sul nodo. Questa capacità viene calcolata come segue:- Modalità Autopilot: capacità inutilizzata nella somma delle richieste di risorse degli elementi Pod sul nodo.
- Modalità standard: capacità inutilizzata nelle risorse del nodo.
spec.nodeSelector
espec.tolerations
: facoltativi. Aggiungi questi campi con etichette personalizzate comepod-type: "non-critical"
per indicare a GKE di creare nuovi nodi per eseguire i pod espandibili. GKE applica incompatibilità a questi nuovi nodi per prevenire I pod, come carichi di lavoro critici, vengono eseguiti sugli stessi nodi. Autopilot applica richieste di risorse minime più elevate per i pod che utilizzano la separazione dei carichi di lavoro. Per maggiori dettagli, vedi Configura la separazione dei carichi di lavoro in GKE e Richieste di risorse in Autopilot.
Esegui il deployment del carico di lavoro:
kubectl apply -f burstable-deployment.yaml
L'avvio del carico di lavoro potrebbe richiedere alcuni minuti.
Controlla la classe QoS di un pod:
kubectl describe pod helloweb | grep -m 1 "QoS"
L'output è il seguente:
QoS Class: Burstable
Capacità condivisibile in GKE
Per facilitare il bursting dei pod, GKE calcola la capacità di bursting per ciascun nodo in un cluster. Questo calcolo per un nodo specifico è il seguente:
Cluster Autopilot:
- Pod che richiedono acceleratori o serie di macchine specifiche: la capacità di risorse allocabile del nodo, ovvero la capacità disponibile per l'utilizzo del carico di lavoro. Per maggiori dettagli, consulta Risorse allocabili del nodo.
- Tutti gli altri pod: la somma delle richieste di risorse di tutti i pod su quel nodo, indipendentemente dalla capacità di risorse effettiva del nodo. Se un pod viene terminati, la capacità di burstable viene ridotta dalle richieste di quel pod. La parte della capacità espandibile non in uso dai pod in esecuzione è disponibile per l'allocazione se uno dei pod deve espandersi.
Autopilot aggiunge anche un buffer predefinito alla capacità espandibile in modo che i pod di sistema sul nodo che superano le loro richieste non influiscano sui tuoi pod espandibili.
Cluster standard: la capacità delle risorse allocabili del nodo, ovvero la capacità disponibile per l'utilizzo del carico di lavoro. Per maggiori dettagli, consulta Risorse allocabili dei nodi.
Best practice per l'esplosione
Utilizza le seguenti best practice con il bursting dei pod:
- Imposta le richieste di risorse in modo che corrispondano ai limiti per tutti i pod che forniscono
una funzionalità più critica
nel tuo ambiente. Questo assicura che i pod ricevano
la classe Quality of Service (QoS) di Kubernetes
Guaranteed
. - Assicurati di configurare il bursting della memoria solo sui pod che possono gestire la rimossa quando Kubernetes deve recuperare memoria sul nodo.
- Richiedi sempre memoria sufficiente per l'avvio del pod. Non fare affidamento sull'aumento della memoria per soddisfare i requisiti di avvio.
- Per evitare che i pod espandibili che si espandono in modo coerente in multipli delle loro richieste di CPU possano interrompere i carichi di lavoro critici, utilizza la separazione dei carichi di lavoro per evitare di posizionare questi pod insieme ai pod critici.
Ottimizzare la capacità espandibile nei nodi Autopilot
Autopilot calcola la capacità espandibile come somma delle richieste di risorse di tutti i pod su un nodo specifico, inclusi i pod di sistema e i DaemonSet. Puoi ottimizzare la capacità espandibile su un nodo nei modi seguenti. Tuttavia, il bursting è opportunistico e non è garantito.
- Per aumentare la capacità di burstable sui nodi per carichi di lavoro specifici, usa Affinità pod per posizionare pod specifici sullo stesso nodo.
- Per garantire che su ogni nodo sia sempre disponibile una specifica capacità di burstable, crea DaemonSets su tutti i nodi nel cluster.
Esempio di come funziona il bursting
Questa sezione utilizza un deployment di esempio con i seguenti pod espandibili per dimostrare come funziona l'espansione dei pod nei cluster GKE Autopilot:
- Il pod 1 richiede 250 milioni di CPU e non ha un limite di CPU. Il pod 1 utilizza 100 m di CPU per l'esecuzione.
- Il pod 2 richiede 200 m di CPU e ha un limite di 250 m CPU. L'esecuzione del pod 2 utilizza 100 m di CPU.
Entrambi i pod vengono eseguiti sullo stesso nodo. La capacità totale espandibile sul nodo è di 450 milioni di CPU (la somma delle richieste di risorse). L'esecuzione di ogni pod utilizza solo 100 m di CPU, il che significa che il nodo ha una capacità disponibile di burstable rimanente di 250 m.
Considera i seguenti scenari in cui si verifica un picco di traffico:
- Il pod 1 ha bisogno di una CPU aggiuntiva di 300 m: può eseguire il burst e utilizzare CPU da 250 m, la capacità di burstable disponibile. Il nodo non ha più capacità aggiuntiva disponibile.
- Il pod 2 ha bisogno di una CPU aggiuntiva di 150 m: può eseguire il burst e utilizzare una CPU da 150 m in più. Il nodo ha quindi 100 milioni di CPU rimanenti di capacità espandibile disponibile.
- Il pod 2 ha bisogno di altri 200 milioni di CPU: può eseguire un picco e utilizzare 150 milioni di CPU, portando l'utilizzo totale a 250 milioni di CPU per il pod 2. Il pod 2 ha un limite di CPU di 250 m e non può esplodere oltre quel limite.
Come GKE gestisce i pod che superano la capacità espandibile
Se i pod espandibili tentano di utilizzare più risorse rispetto alla capacità espandibile sul nodo, GKE esegue le seguenti azioni:
- CPU: se l'utilizzo della CPU supera la capacità di picco, GKE limita l'utilizzo della CPU di alcuni container in modo che tutti i container sul nodo ricevano la CPU richiesta.
- Memoria: se l'utilizzo della memoria supera la capacità espandibile, GKE termina i container per recuperare la memoria sul nodo. GKE inizia a terminare i container che richiedono molte risorse nei pod con una QoS inferiore.
Ti consigliamo di richiedere sempre memoria sufficiente per il normale funzionamento dei pod. Se un contenitore ha una dipendenza dall'aumento della memoria per funzionare normalmente, potrebbe verificarsi un arresto anomalo ripetuto se la memoria non è disponibile.
Utilizza il bursting dei pod con il provisioning della capacità di riserva
GKE ti consente di eseguire il deployment di pod inattivi per prenotare capacità di calcolo aggiuntiva per una scalabilità dei pod più rapida durante eventi futuri a traffico elevato come il flash dei negozi online vendite. Altri pod sullo stesso nodo possono eseguire il burst in questa capacità prenotata inutilizzata in modo che la capacità non rimanga inattiva nel tempo che conduce al traffico elevato . Puoi prenotare questa capacità utilizzando vari meccanismi Kubernetes. Ad esempio, puoi eseguire il deployment di pod con un PriorityClass basso. Per maggiori dettagli, consulta Provisioning di capacità di calcolo aggiuntiva per il ridimensionamento rapido dei pod.
Bursting dei pod nei cluster GKE Standard
I cluster GKE Standard supportano anche il bursting dei pod impostando limiti superiori alle richieste o omettendo dei limiti. Tuttavia, nei cluster standard devi creare e configurare pool di nodi con la capacità di risorse appropriata per supportare l'esplosione. Per ottenere la potenziale riduzione dei costi dei pod espandibili nei cluster standard, è necessaria una pianificazione più attenta dei nodi e il bin-packing dei pod, perché paghi le VM Compute Engine sottostanti.
Considera quanto segue nei cluster Standard:
Il limite massimo di consumo delle risorse che attiva l'espulsione di Kubernetes o il throttling della CPU è la capacità delle risorse allocabili sul nodo. Per determinare questo valore, consulta Pianifica le dimensioni dei nodi GKE Standard.
L'utilizzo delle risorse dei nodi nei cluster standard ha maggiori probabilità di raggiungere Soglia di eliminazione di Kubernetes perché GKE non limita automaticamente e il consumo di risorse se non specifichi limiti. Pertanto, i pod che consumano molta memoria hanno maggiori probabilità di essere terminati da Kubernetes tramite l'espulsione per pressione del nodo.
Passaggi successivi
- Provisioning di capacità di calcolo aggiuntiva per la scalabilità rapida dei pod
- Ridimensiona i tuoi carichi di lavoro GKE Standard su larga scala