Configurare il bursting dei pod in GKE

Questa pagina mostra come configurare i pod per utilizzare la capacità inutilizzata disponibile sui nodi Google Kubernetes Engine (GKE).

Che cos'è il bursting?

Il bursting descrive l'azione dei pod che utilizzano temporaneamente una capacità di calcolo maggiore sul nodo rispetto a quella originariamente richiesta.

Kubernetes ti consente di richiedere capacità specifiche di risorse come CPU o memoria per i tuoi pod. Queste richieste vengono impostate nel manifest del pod. Lo scheduler Kubernetes posiziona i pod sui nodi che hanno capacità sufficiente per soddisfare le richieste di risorse.

Alcuni workload non utilizzano il 100% delle risorse richieste per l'intera durata di esecuzione. Ad esempio, un workload che consuma CPU aggiuntiva durante il periodo di avvio potrebbe non richiedere la stessa quantità di risorse per le operazioni normali. In queste situazioni, puoi impostare i limiti delle risorse per il tuo workload su un valore superiore 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 maggiori informazioni su come funziona questo processo in GKE, consulta la sezione Capacità burst in GKE in questa pagina.

Vantaggi del pod bursting

Il bursting è utile quando i pod hanno bisogno di risorse aggiuntive solo per brevi periodi di tempo per far fronte ai picchi di utilizzo delle risorse. Ecco alcuni scenari di esempio:

• Hai gruppi di workload spesso inattivi che inviano un numero ridotto di richieste al secondo, ma occasionalmente registrano picchi di traffico e trarrebbero vantaggio da risorse aggiuntive per elaborare queste richieste.
• I tuoi carichi di lavoro hanno bisogno di 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 pod ha bisogno per la maggior parte del runtime, garantendo al contempo che il pod possa consumare più risorse se necessario. I vantaggi del bursting includono:

• Costi di esecuzione inferiori: non è necessario richiedere il consumo di risorse di picco previsto del workload. Le richieste possono riguardare i valori di stato stazionario inferiori. In Autopilot, paghi la somma delle richieste di risorse del pod, quindi i costi di esecuzione sono inferiori.
• Utilizzo più efficiente delle risorse: eviti la capacità di calcolo inattiva perché i tuoi pod utilizzano la capacità inutilizzata. È più probabile che i tuoi carichi di lavoro utilizzino tutte le risorse a pagamento.
• Prestazioni migliorate: i pod possono utilizzare risorse aggiuntive in base alle necessità per ridurre il tempo di elaborazione delle richieste in entrata o per avviarsi più rapidamente durante gli eventi di scale up.

Quando non utilizzare il bursting

Kubernetes assegna la classe Burstable Quality of Service (QoS) ai pod che specificano limiti di risorse superiori rispetto alle richieste. Burstable I pod QoS hanno maggiori probabilità di essere eliminati quando Kubernetes deve recuperare risorse sul nodo. Per saperne di più, consulta 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à, installala e poi inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.

• Assicurati di avere un cluster GKE Autopilot che esegue la versione 1.30.2-gke.1394000 o successive oppure qualsiasi versione di un cluster GKE Standard. Per creare un nuovo cluster, consulta Crea un cluster Autopilot.

Disponibilità del bursting in GKE

I carichi di lavoro possono aumentare nei seguenti casi:

Limitazioni

• I workload Autopilot possono utilizzare il bursting 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 alla versione del control plane nel tempo. Per abilitare il bursting è necessario riavviare il control plane, che deve avvenire dopo che tutti i nodi eseguono una versione supportata e una modalità cgroup supportata. Il control plane viene riavviato automaticamente circa una volta alla settimana durante operazioni come scalabilità, upgrade o manutenzione.

  Per attivare manualmente il riavvio del control plane:

  1. Verifica che tutti i nodi eseguano la versione 1.30.2-gke.1394000 o successive:

     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 versione successiva.

  2. Verifica che il cluster esegua cgroupv2. Per istruzioni, vedi Controllare la modalità cgroup.

  3. Avvia manualmente un upgrade del control plane alla stessa versione già utilizzata dal cluster.

     gcloud container clusters upgrade CLUSTER_NAME --master \
         --cluster-version CURRENT_CLUSTER_VERSION
     

     Sostituisci quanto segue:

     • CLUSTER_NAME: il nome del cluster esistente.
     • CURRENT_CLUSTER_VERSION: la versione in esecuzione del cluster.

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.

Verifica che il cluster supporti il bursting

Il bursting è sempre abilitato nei cluster in modalità Standard e per i carichi di lavoro in modalità Autopilot che richiedono acceleratori o serie di macchine specifiche. Vai alla sezione Esegui il deployment di un carico di lavoro burstable.

I seguenti tipi di carichi di lavoro Autopilot possono eseguire burst solo se nel cluster è in esecuzione un DaemonSet gestito da GKE denominato efficiency-daemon:

• Pod Autopilot che richiedono le Scale-Out o Balanced classi di computing predefinite.
• Pod Autopilot che non richiedono una classe di computing.

GKE esegue il deployment di DaemonSet efficiency-daemon quando il tuo cluster Autopilot soddisfa i requisiti per il bursting, come descritto nella sezione Disponibilità del bursting in GKE.

Per verificare se il DaemonSet efficiency-daemon esiste nel tuo cluster, esegui questo comando:

kubectl get daemonset --namespace=kube-system efficiency-daemon

L'output è simile al seguente:

NAME                DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
efficiency-daemon   1         1         1       1            1           <none>          105d

Se l'output è vuoto, assicurati che il cluster soddisfi tutti i requisiti e le limitazioni nella sezione Prima di iniziare.

Esegui il deployment di un carico di lavoro burstable

1. 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 ha i seguenti campi per attivare il bursting:

   • resources.requests: le risorse necessarie al container per funzionare. Imposta questo valore sulla capacità di cui avrà bisogno il container in stato stazionario.
   • resources.limits: la capacità massima delle risorse che il container può utilizzare. Se imposti i limiti superiori alle richieste, i pod possono aumentare fino al limite specificato se la capacità è disponibile sul nodo. Se ometti questo campo, i pod possono raggiungere la capacità burstable disponibile sul nodo. Questa capacità viene calcolata come segue:
     • Modalità Autopilot: capacità inutilizzata nella somma delle richieste di risorse dei pod sul nodo.
     • Modalità Standard: capacità inutilizzata nelle risorse del nodo.
   • spec.nodeSelector e spec.tolerations: facoltativi. Aggiungi questi campi con etichette personalizzate come pod-type: "non-critical" per indicare a GKE di creare nuovi nodi per eseguire i pod burstable. GKE applica incompatibilità a questi nuovi nodi per impedire l'esecuzione di altri pod, come i carichi di lavoro critici, sugli stessi nodi. Autopilot applica richieste di risorse minime più elevate per i pod che utilizzano la separazione dei workload. Per i dettagli, consulta Configurare la separazione dei workload in GKE e Richieste di risorse in Autopilot.

2. Esegui il deployment del carico di lavoro:

   kubectl apply -f burstable-deployment.yaml
   

   L'avvio del carico di lavoro potrebbe richiedere alcuni minuti.

3. Controlla la classe QoS di un pod:

   kubectl describe pod helloweb | grep -m 1 "QoS"
   

   L'output è il seguente:

   QoS Class: Burstable
   

Capacità burstable in GKE

Per facilitare il bursting dei pod, GKE calcola la capacità burstable per ogni nodo di un cluster. Il calcolo per un nodo specifico è il seguente:

• Cluster Autopilot:

  • Pod che richiedono acceleratori o serie di macchine specifiche: la capacità di risorse allocabili del nodo, ovvero la capacità disponibile per l'utilizzo del carico di lavoro. Per i dettagli , vedi Risorse allocabili dei nodi.
  • Tutti gli altri pod: la somma delle richieste di risorse di tutti i pod sul nodo, indipendentemente dalla capacità effettiva delle risorse del nodo. Se un pod viene terminato, la capacità burstable si riduce in base alle richieste del pod. La parte della capacità burstable non utilizzata dai pod in esecuzione è disponibile per l'allocazione se uno dei pod deve eseguire il burst.

  Autopilot aggiunge anche un buffer predefinito alla capacità burstable in modo che i pod di sistema sul nodo che superano le richieste non influiscano sui tuoi pod burstable.

• Cluster standard: la capacità delle risorse allocabili dei nodi, ovvero la capacità disponibile per l'utilizzo del workload. Per i dettagli , vedi Risorse allocabili dei nodi.

Best practice per il bursting

Utilizza le seguenti pratiche con l'utilizzo in burst dei pod:

• Imposta le richieste di risorse in modo che corrispondano ai limiti per tutti i pod che forniscono funzionalità critiche nel tuo ambiente. In questo modo, questi pod ottengono la classe di qualità del servizio (QoS) Guaranteed di Kubernetes.
• Assicurati di configurare l'utilizzo in burst della memoria solo sui pod che possono gestire l'espulsione quando Kubernetes deve recuperare memoria sul nodo.
• Richiedi sempre memoria sufficiente per l'avvio del pod. Non fare affidamento sul memory bursting per soddisfare i requisiti di avvio.
• Per evitare che i pod burstable che eseguono costantemente burst in multipli delle richieste di CPU interrompano potenzialmente i workload critici, utilizza la separazione dei workload per evitare di posizionare questi pod insieme a quelli critici.

Ottimizzare la capacità burstable nei nodi Autopilot

Autopilot calcola la capacità burstable 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à burstable di un nodo nei seguenti modi. Tuttavia, il bursting è opportunistico e non è garantito.

• Per aumentare la capacità burstable sui nodi per carichi di lavoro specifici, utilizza Pod affinity per posizionare pod specifici insieme sullo stesso nodo.
• Per assicurarti che una capacità burstable specifica sia sempre disponibile su ogni nodo, crea DaemonSets da eseguire su tutti i nodi del cluster.

Esempio di come funziona il bursting

Questa sezione utilizza un deployment di esempio con i seguenti pod burstable per mostrare come funziona il burst dei pod nei cluster GKE Autopilot:

• Il pod 1 richiede 250 m 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 di CPU. Il pod 2 utilizza 100 m di CPU per l'esecuzione.

Entrambi i pod vengono eseguiti sullo stesso nodo. La capacità burstable totale sul nodo è 450 mCPU (la somma delle richieste di risorse). Ogni pod utilizza solo 100 m di CPU per l'esecuzione, il che significa che il nodo ha una capacità burstable disponibile rimanente di 250 m.

Considera i seguenti scenari in cui si verifica un picco di traffico:

• Il pod 1 ha bisogno di 300 m CPU aggiuntivi: può eseguire il burst e utilizzare 250 m CPU, ovvero la capacità di burst disponibile. Il nodo non ha più capacità burstable disponibile.
• Il pod 2 ha bisogno di altri 150 m di CPU: può eseguire burst e utilizzare 150 m di CPU aggiuntivi. Il nodo ha quindi 100 m di CPU rimanenti della capacità burstable disponibile.
• Il pod 2 ha bisogno di altri 200 m di CPU: può eseguire burst e utilizzare 150 m di CPU, il che porta l'utilizzo totale a 250 m di CPU per il pod 2. Il pod 2 ha un limite di CPU di 250 m e non può superare questo limite.

Come GKE gestisce i pod che superano la capacità burst

Se i pod burstable tentano di utilizzare più risorse della capacità burstable sul nodo, GKE esegue le seguenti azioni:

• CPU: se l'utilizzo della CPU supera la capacità burstable, 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à burstable, GKE termina i container per recuperare memoria sul nodo. GKE inizia terminando i container che utilizzano molte risorse nei pod con una QoS inferiore.

Ti consigliamo di richiedere sempre memoria sufficiente per il normale funzionamento del pod. Se un contenitore dipende dal bursting della memoria per funzionare normalmente, potrebbe arrestarsi in modo anomalo ripetutamente se la memoria non è disponibile.

Utilizzare l'overflow dei pod con il provisioning della capacità di riserva

GKE ti consente di eseguire il deployment di pod inattivi per riservare capacità di calcolo aggiuntiva per una scalabilità più rapida dei pod durante eventi futuri con traffico elevato, come le vendite lampo dei negozi online. Gli altri pod sullo stesso nodo possono utilizzare questa capacità riservata inutilizzata in modo che la capacità non sia inattiva nel periodo precedente l'evento con traffico elevato. Puoi riservare questa capacità utilizzando vari meccanismi di Kubernetes. Ad esempio, puoi eseguire il deployment di pod con una PriorityClass bassa. Per maggiori dettagli, vedi Eseguire il provisioning di capacità di calcolo aggiuntiva per lo scaling rapido dei pod.

Bursting dei pod nei cluster GKE Standard

I cluster GKE Standard supportano anche il bursting dei pod impostando i limiti superiori alle richieste o omettendo i limiti. Tuttavia, nei cluster Standard devi creare e configurare i node pool con una capacità di risorse appropriata per supportare il bursting. Per ottenere la potenziale riduzione dei costi dei pod burstable nei cluster Standard è necessaria una pianificazione più attenta dei nodi e del 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 la limitazione della CPU è la capacità delle risorse allocabili sul nodo. Per determinare questo valore, consulta Pianificare le dimensioni dei nodi GKE Standard.

• L'utilizzo delle risorse dei nodi nei cluster Standard ha maggiori probabilità di raggiungere una soglia di espulsione di Kubernetes perché GKE non limita automaticamente il consumo di risorse se non specifichi limiti. I pod che utilizzano una quantità eccessiva di memoria hanno quindi maggiori probabilità di essere terminati da Kubernetes con l'espulsione node-pressure.

Passaggi successivi

• Esegui il provisioning di capacità di calcolo aggiuntiva per lo scaling rapido dei pod
• Dimensiona correttamente i carichi di lavoro GKE Standard su larga scala