Configura Pod bursting in GKE

Questa pagina mostra come configurare i pod per l'utilizzo temporaneo della capacità inutilizzata disponibile sui nodi Google Kubernetes Engine (GKE).

Che cos'è il bursting?

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

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 su nodi con capacità sufficiente per soddisfare queste richieste di risorse.

Alcuni workload non utilizzano il 100% delle risorse richieste per l'intero tempo 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 workload 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à di burst in GKE in questa pagina.

Vantaggi del bursting dei pod

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 che sono spesso inattivi e 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 workload 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 pod ha bisogno per la maggior parte del runtime e contribuisce a garantire 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 tue richieste possono essere per i valori di stato stabile inferiori. In Autopilot, paghi per la somma delle richieste di risorse dei pod, quindi i costi di gestione sono inferiori.
  • Utilizzo più efficiente delle risorse: eviti la capacità di calcolo inattiva perché i pod utilizzano la capacità inutilizzata. È più probabile che i tuoi workload utilizzino tutte le risorse per cui hai pagato.
  • Prestazioni migliorate: i pod possono utilizzare risorse aggiuntive in base alle esigenze per ridurre il tempo di elaborazione delle richieste in entrata o per avviarsi più velocemente durante gli eventi di scale up.

Quando non utilizzare il bursting

Kubernetes assegna la classe Quality of Service (QoS) Burstable ai pod che specificano limiti delle risorse superiori alle richieste. I pod con QoS Burstable hanno maggiori probabilità di essere rimossi quando Kubernetes deve recuperare risorse sul nodo. Per saperne di più, consulta la sezione Classe QoS burstable nella documentazione di Kubernetes.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Abilita l'API Google Kubernetes Engine.
    • Abilita l'API Google Kubernetes Engine
  • Per utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
  • Assicurati di avere un cluster GKE Autopilot con versione 1.30.2-gke.1394000 o successiva o qualsiasi versione di un cluster GKE Standard. Per creare un nuovo cluster, vedi Crea un cluster Autopilot.

Disponibilità del bursting in GKE

I workload possono fare bursting nelle seguenti situazioni:

Disponibilità del bursting
Modalità GKE Autopilot

I seguenti tipi di pod possono eseguire il bursting in qualsiasi versione di GKE che supporti l'hardware richiesto dai pod:

Per tutti gli altri tipi di pod, il bursting diventa disponibile quando riavvii il control plane dopo aver verificato che il cluster soddisfi tutte le seguenti condizioni:

  • Il cluster esegue cgroupv2. I cluster creati con GKE versione 1.26 o successiva o di cui è stata eseguita la migrazione a cgroupv2 soddisferanno questa condizione. Consulta Controlla la modalità cgroup per determinare la versione attuale di cgroup ed esegui la migrazione, se necessario.
  • Il cluster esegue GKE versione 1.30.2-gke.1394000 o successive.

Per maggiori dettagli, consulta Limitazioni.
Modalità GKE Standard I pod possono eseguire il bursting in qualsiasi versione di GKE.

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 attivare il bursting, è necessario riavviare il control plane, operazione che deve avvenire dopo che tutti i nodi eseguono una versione e una modalità cgroup supportate. Il control plane si riavvia automaticamente circa una volta alla settimana durante operazioni come scalabilità, upgrade o manutenzione.

    Per attivare manualmente un riavvio del control plane:

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

    2. Verifica che il cluster esegua cgroupv2. Per istruzioni, consulta Controlla 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 tuo cluster esistente.
      • CURRENT_CLUSTER_VERSION: la versione in esecuzione nel cluster.

Connettiti al cluster

Esegui questo comando:

gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del tuo cluster esistente.
  • LOCATION: la località del tuo cluster.

Verifica che il cluster supporti il bursting

Il bursting è sempre abilitato nei cluster in modalità Standard e per i workload in modalità Autopilot che richiedono acceleratori o serie di macchine specifiche. Vai alla sezione Esegui il deployment di un workload con possibilità di burst.

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

GKE esegue il deployment del 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 il seguente 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 workload estendibile

  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 contiene i seguenti campi per abilitare il bursting:

    • resources.requests: le risorse necessarie per il funzionamento del container. Imposta questo valore sulla capacità di cui il container avrà bisogno nello stato stabile.
    • resources.limits: la capacità massima delle risorse che il container può utilizzare. Se imposti i limiti su un valore superiore alle richieste, i pod possono aumentare fino al limite specificato se questa capacità è disponibile sul nodo. Se ometti questo campo, i pod possono raggiungere la capacità di burst 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 dei nodi.
    • 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 con burst. GKE applica incompatibilità a questi nuovi nodi per impedire l'esecuzione di altri pod, come i workload critici, sugli stessi nodi. Autopilot applica richieste di risorse minime più elevate per i pod che utilizzano la separazione dei workload. Per maggiori dettagli, consulta Configura la separazione dei workload in GKE e Richieste di risorse in Autopilot.

  2. Esegui il deployment del workload:

    kubectl apply -f burstable-deployment.yaml

    L'avvio del workload 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à di burst in GKE

Per facilitare il bursting dei pod, GKE calcola la capacità di burst 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à delle risorse allocabili del nodo, ovvero la capacità disponibile per l'utilizzo del workload. Per maggiori dettagli , consulta Risorse allocabili dei nodi.
    • Tutti gli altri pod: la somma delle richieste di risorse di tutti i pod su quel nodo, indipendentemente dalla capacità effettiva delle risorse del nodo. Se un pod viene terminato, la capacità di burst si riduce in base alle richieste del pod. La parte della capacità di burst 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à di burst, in modo che i pod di sistema sul nodo che eseguono il burst oltre le richieste non influiscano sui pod con burst.

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

Best practice per il bursting

Utilizza le seguenti pratiche con il bursting dei pod:

  • Imposta le richieste di risorse in modo che corrispondano ai limiti per tutti i pod che forniscono funzionalità critiche nel tuo ambiente. Questo approccio contribuisce a garantire che i pod ricevano la classe di qualità del servizio (QoS) Kubernetes Guaranteed.
  • Assicurati di configurare il bursting 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 bursting della memoria per soddisfare i requisiti di avvio.
  • Per evitare che i pod burstable che eseguono costantemente il bursting in multipli delle loro richieste di CPU possano interrompere i workload critici, utilizza la separazione dei workload per evitare di posizionare questi pod insieme ai pod critici.

Ottimizza la capacità di burst nei nodi Autopilot

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

  • Per aumentare la capacità di burst sui nodi per workload specifici, utilizza l'affinità pod per posizionare pod specifici insieme sullo stesso nodo.
  • Per assicurarti che una capacità di burst specifica sia sempre disponibile su ogni nodo, crea DaemonSets da eseguire su tutti i nodi del cluster.

Esempio di funzionamento del bursting

Questa sezione utilizza un deployment di esempio con i seguenti pod burstable per dimostrare come funziona il bursting 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à di burst totale sul nodo è di 450 m di CPU (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à di burst disponibile rimanente di 250 m.

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

  • Il pod 1 ha bisogno di altri 300 m di CPU: può eseguire il bursting e utilizzare 250 m di CPU, ovvero la capacità di burst disponibile. Il nodo non ha più capacità di burst disponibile.
  • Il pod 2 ha bisogno di altri 150 m di CPU: può eseguire il burst e utilizzare altri 150 m di CPU. Il nodo ha quindi 100 m di CPU rimanenti di capacità di burst disponibile.
  • Il pod 2 ha bisogno di altri 200 m di CPU: può eseguire il bursting 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ò superarlo.

In che modo GKE gestisce i pod che superano la capacità di burst

Se i pod con possibilità di burst tentano di utilizzare più risorse della capacità di burst sul nodo, GKE intraprende le seguenti azioni:

  • CPU: se l'utilizzo della CPU supera la capacità di burst, GKE limita l'utilizzo della CPU di alcuni container in modo che tutti i container sul nodo ricevano la CPU richiesta.
  • Memoria: se la memoria utilizzata supera la capacità di burst, GKE termina i container per recuperare memoria sul nodo. GKE inizia terminando i container ad alta intensità di risorse nei pod con una QoS inferiore.

Ti consigliamo di richiedere sempre memoria sufficiente per il normale funzionamento dei pod. Se un container dipende dal bursting della memoria per funzionare normalmente, potrebbe arrestarsi in modo anomalo ripetutamente 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 computing aggiuntiva per un ridimensionamento più rapido dei pod durante eventi futuri con traffico elevato, come le offerte lampo dei negozi online. Altri pod sullo stesso nodo possono utilizzare questa capacità riservata inutilizzata, in modo che non rimanga inattiva nel periodo che precede l'evento con traffico elevato. Puoi prenotare questa capacità utilizzando vari meccanismi di Kubernetes. Ad esempio, puoi eseguire il deployment di pod con una PriorityClass bassa. Per maggiori dettagli, consulta Esegui il provisioning di capacità di computing aggiuntiva per la scalabilità rapida 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 i limiti. Tuttavia, nei cluster Standard, devi creare e configurare i node pool con una capacità delle risorse appropriata per supportare il bursting. Per ottenere la potenziale riduzione dei costi dei pod espandibili nei cluster Standard, è necessaria una pianificazione più attenta dei nodi e del bin packing dei pod, perché paghi per le VM di Compute Engine sottostanti.

Tieni presente quanto segue per i 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 Pianifica 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 i limiti. I pod che utilizzano molta memoria hanno quindi maggiori probabilità di essere terminati dall'eliminazione per pressione sui nodi di Kubernetes.

Passaggi successivi