Configura il bursting dei pod in GKE

Questa pagina mostra come configurare i pod per eseguire il burst nella capacità disponibile inutilizzata sui nodi Google Kubernetes Engine (GKE).

Cos'è un bursting?

Bursting descrive l'azione dei pod temporaneamente utilizzando più capacità di calcolo sul nodo rispetto a quella richiesta in origine.

Kubernetes consente di richiedere capacità specifiche di risorse come CPU o memoria per i tuoi pod. Devi impostare queste richieste nel manifest del pod. Lo scheduler Kubernetes posiziona i pod in nodi con capacità sufficiente per soddisfare tali richieste di risorse.

Alcuni carichi di lavoro non utilizzano il 100% delle risorse richieste per l'intero tempo di esecuzione. Ad esempio, un carico di lavoro che consuma più CPU durante il periodo di avvio potrebbe non richiedere la stessa quantità di risorse per le normali operazioni. In queste situazioni, è possibile impostare i limiti delle risorse per il carico di lavoro su un valore superiore rispetto alle richieste di risorse oppure 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 ulteriori informazioni su come funziona questo processo in GKE, consulta Capacità cumulabile in GKE in questo documento.

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 a picchi di utilizzo delle risorse. Ecco alcuni scenari di esempio:

  • Hai gruppi di carichi di lavoro che sono spesso inattivi e inviano un piccolo numero di richieste al secondo, ma a volte si verificano picchi di traffico e potrebbero trarre vantaggio da risorse aggiuntive per elaborare queste richieste.
  • I carichi di lavoro hanno bisogno di più risorse durante l'avvio rispetto al normale funzionamento.
  • Vuoi massimizzare l'utilizzo della capacità di calcolo di cui esegui il provisioning.

Il bursting consente di richiedere solo le risorse necessarie al pod per la maggior parte del runtime, garantendo al contempo che il pod possa consumare più risorse se necessario. I vantaggi del bursting includono quanto segue:

  • Riduzione dei costi di esecuzione: non è necessario richiedere il picco di consumo delle risorse del carico di lavoro. Le tue richieste possono riguardare valori di stato stazionari inferiori. In Autopilot, paghi la somma delle richieste di risorse dei pod, quindi i costi di esecuzione sono inferiori.
  • Utilizzo delle risorse più efficiente: eviterai capacità di calcolo inattiva perché i tuoi pod hanno una capacità di burst inutilizzata. È più probabile che i carichi di lavoro utilizzino tutte le tue risorse a pagamento.
  • 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 usare la funzionalità di bursting

Kubernetes assegna la classe Burstable Qualità del servizio (QoS) ai pod che specifica limiti di risorse più elevati rispetto alle relative richieste. Burstable I pod di QoS hanno maggiori probabilità di essere rimossi quando Kubernetes deve recuperare risorse sul nodo. Per ulteriori informazioni, consulta Classe QoS Burst nella documentazione 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
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installa e quindi initialize gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.
  • Assicurati di avere un cluster GKE Autopilot in esecuzione 1.29.2-gke.1060000 o versioni successive oppure qualsiasi versione di un cluster GKE Standard. Per creare un nuovo cluster, consulta Creare un cluster Autopilot.

Disponibilità di bursting in GKE

I carichi di lavoro possono eseguire il burst nelle seguenti situazioni:

Disponibilità di bursting
Modalità GKE Autopilot

I pod che utilizzano la classe di computing Performance o la classe di calcolo Accelerator possono eseguire il burst in qualsiasi versione di GKE che supporti quella classe di calcolo.

In qualsiasi altra classe di computing e per i pod che non specificano una classe di computing, il bursting è disponibile solo se il cluster soddisfa entrambe le seguenti condizioni:

  • Inizialmente hai creato il cluster con GKE versione 1.26 o successiva
  • Il cluster esegue GKE versione 1.29.2-gke.1060000 o successiva

Questa limitazione esiste perché, nei cluster Autopilot, il bursting richiede cgroup v2. cgroup v2 è disponibile solo nei cluster 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 originariamente con una versione precedente alla 1.26 e successivamente aggiornati alla 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 bursting solo per le richieste di CPU e memoria.
  • I piani di controllo e i nodi Autopilot devono utilizzare una versione di GKE supportata. Se di recente hai eseguito l'upgrade dei cluster a una versione supportata, assicurati che i nodi stiano eseguendo quella versione prima di utilizzare il bursting.

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 località del cluster.

Esegui il deployment di un carico di lavoro con possibilità di burst

  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:
      nodeSelector:
        pod-type: "non-critical"
      tolerations:
      - key: pod-type
        operator: Equal
        value: "non-critical"
        effect: NoSchedule
      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

    Il file manifest contiene i seguenti campi per abilitare il bursting:

    • resources.requests: le risorse necessarie per il funzionamento del container. Imposta questo valore sulla capacità necessaria al container in stato stabile.
    • resources.limits: la capacità massima delle risorse che il container può utilizzare. L'impostazione di limiti superiori alle richieste consente ai pod di eseguire il burst fino al limite specificato se la capacità è disponibile sul nodo. Se ometti questo campo, i pod possono eseguire il burst fino alla 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 del nodo.
    • spec.nodeSelector e spec.tolerations: facoltativi. Comunica a GKE di creare nuovi nodi per eseguire i pod con possibilità di burst. GKE applica le incompatibilità a questi nuovi nodi per impedire l'esecuzione di altri pod, come carichi di lavoro critici, sugli stessi nodi. Per maggiori dettagli, consulta Configurare la separazione dei carichi di lavoro in GKE.

  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à 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: 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 burstable si riduce in base alle richieste di quel pod. La parte della capacità con possibilità di burst non in uso durante l'esecuzione dei pod è disponibile per allocare se uno dei pod deve eseguire il burst.

    Autopilot aggiunge anche un buffer predefinito alla capacità di burst, in modo che tutti i pod di sistema sul nodo che eseguono il burst oltre le loro richieste non influiscano sui tuoi pod con possibilità di burst.

  • Cluster standard: la capacità totale delle risorse disponibile sulla VM del nodo.

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. Ciò garantisce che i pod ricevano la classe Guaranteed di qualità del servizio (QoS) di Kubernetes.
  • Assicurati di configurare il bursting della memoria solo sui pod che possono gestire l'eliminazione 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 con bursting che eseguono burst in modo coerente in multipli delle richieste della CPU causando potenzialmente l'interruzione dei carichi di lavoro critici, utilizza la separazione dei carichi di lavoro per evitare di posizionare questi pod insieme ai pod critici.

Ottimizza la capacità di burstable nei nodi Autopilot

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

  • Per aumentare la capacità di burstable sui nodi per carichi di lavoro specifici, utilizza l'affinità dei pod per posizionare pod specifici sullo stesso nodo.
  • Per garantire che su ogni nodo sia sempre disponibile una specifica capacità di burstable, crea dei DaemonSets da eseguire su tutti i nodi nel cluster.

Esempio di come funziona il bursting

Questa sezione utilizza un deployment di esempio con i seguenti pod con possibilità di bursting per dimostrare come funziona il bursting dei pod nei cluster GKE Autopilot:

  • Il pod 1 richiede 250 m di CPU e non ha limiti di CPU. L'esecuzione del pod 1 utilizza 100 m di CPU.
  • 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 di burstable sul nodo è 450 m 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 250 m di CPU, ovvero la capacità disponibile di burst. Il nodo non dispone più di capacità con possibilità di burst.
  • 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 dispone quindi di 100 m di CPU rimanenti di capacità burstabile disponibile.
  • Il pod 2 ha bisogno di altri 200 m di CPU: può eseguire il burst e utilizzare 150 m di CPU, portando 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.

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

Se i pod con possibilità di burst provano a utilizzare più risorse rispetto alla capacità di cui è possibile eseguire il burst sul nodo, GKE esegue le seguenti azioni:

  • CPU: se l'utilizzo della CPU supera la capacità di burst, GKE limita l'utilizzo della CPU da parte di alcuni container in modo che tutti quelli sul nodo ricevano la CPU richiesta.
  • Memoria: se l'utilizzo della memoria supera la capacità di burst, GKE termina i container per recuperare memoria sul nodo. GKE termina i container che usano molte risorse nei pod con QoS più bassa.

Ti consigliamo di richiedere sempre memoria sufficiente per il normale funzionamento dei pod. Se un container ha una dipendenza dal bursting della memoria per funzionare normalmente, potrebbe arrestarsi in modo anomalo ripetutamente se quella memoria non è disponibile.

Utilizza il bursting dei pod con il provisioning della capacità di riserva

GKE consente di eseguire il deployment di pod inattivi per riservare capacità di calcolo aggiuntiva per scalare i pod più rapidamente durante eventi futuri a traffico elevato, come le vendite Flash di negozi online. 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 precede l'evento a traffico elevato. Puoi prenotare questa capacità utilizzando vari meccanismi Kubernetes. Ad esempio, puoi eseguire il deployment di pod che hanno un valore PriorityClass basso. Per maggiori dettagli, consulta Eseguire il provisioning di capacità di calcolo aggiuntiva per una rapida scalabilità dei pod.

Bursting dei pod nei cluster GKE Standard

I cluster GKE Standard supportano anche il bursting dei pod impostando i limiti su un valore superiore alle richieste oppure omettendo i limiti. Tuttavia, nei cluster standard, devi creare e configurare pool di nodi con una capacità delle risorse appropriata per supportare il bursting. Ottenere la potenziale riduzione dei costi dei pod con possibilità di burst nei cluster Standard richiede una pianificazione dei nodi più attenta e il bin-packing dei pod, poiché paghi per le VM di Compute Engine sottostanti.

Considera quanto segue nei cluster Standard:

  • Il limite massimo di consumo di risorse che attiva l'eliminazione di Kubernetes o la limitazione della CPU è la capacità delle risorse allocabile 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 eliminazione di Kubernetes, poiché GKE non limita automaticamente il consumo delle risorse se non specifichi dei limiti. I pod che con burst in memoria hanno quindi maggiori probabilità di essere terminati dall'eliminazione della pressione dei nodi di Kubernetes.

Passaggi successivi