Configura il bursting dei pod in GKE

Questa pagina mostra come configurare i pod per eseguire l'esplosione in spazi di archiviazione disponibili 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 quanto richiesto 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. Il cluster Kubernetes scheduler posiziona i pod su nodi con capacità sufficiente per le 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 più CPU durante il periodo di avvio. potrebbero 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 usare temporaneamente più risorse di quelle specificate nelle richieste, se questa capacità è disponibile.

Per saperne di più su come funziona questo processo in GKE, consulta Burstable in GKE in questo documento.

Vantaggi del bursting 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 hanno bisogno di più risorse durante l'avvio rispetto al normale operations.
  • 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:

  • Riduzione dei costi di gestione: non è necessario richiedere il picco previsto il consumo di risorse da parte 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 delle risorse più efficiente: eviterai capacità di calcolo inattiva perché i tuoi pod entrano in capacità inutilizzata. È più probabile che i tuoi carichi di lavoro utilizzino tutte le risorse a pagamento.
  • Prestazioni superiori: i pod possono utilizzare risorse aggiuntive in base alle esigenze per ridurre il tempo necessario per elaborare le richieste in entrata o per un avvio più rapido durante lo scale up eventi.

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, vedi Corso QoS lampo nella documentazione di Kubernetes.

Prima di iniziare

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

  • Attiva l'API Google Kubernetes Engine.
    • Abilita l'API Google Kubernetes Engine .
  • Se vuoi utilizzare Google Cloud CLI per questa attività, install e poi initialize con gcloud CLI. Se hai già installato gcloud CLI, scarica 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 Crea 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

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:

  • Inizialmente hai creato il cluster con la versione GKE 1.26 o versioni successive
  • Il cluster esegue GKE versione 1.30.2-gke.1394000 o successiva

Questa restrizione esiste perché, nei cluster Autopilot, Il bursting richiede cgroup v2. cgroup v2 è disponibile solo nei cluster che sono stati originariamente creati con la versione 1.26 e successive.
Modalità GKE Standard I pod possono eseguire il burst in qualsiasi versione di GKE.

Cluster Autopilot creati originariamente con una versione precedente 1.26 e successivamente è stato eseguito l'upgrade a 1.29.2-gke.1060000 e successivamente non supportano un'esplosione. 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.

  • 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. È necessario riavviare il piano di controllo per abilitare il bursting, e deve verificarsi dopo che tutti i nodi hanno eseguito una versione supportata. Il piano di controllo si riavvia automaticamente circa una volta alla settimana durante operazioni come la scalabilità, upgrade o manutenzione.

    Per attivare manualmente il riavvio di un piano di controllo:

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

    2. Avvia manualmente l'upgrade di un piano di controllo alla stessa versione di un cluster Kubernetes. 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 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 container personalizzata. Imposta questo valore sulla capacità necessaria al container in stato stabile.
    • resources.limits: la capacità massima delle risorse che il container può per gli utilizzi odierni. 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 dei pod sul nodo.
      • Modalità standard: capacità inutilizzata nelle risorse del nodo.
    • spec.nodeSelector e spec.tolerations: facoltativi. Dice a GKE di creare nuovi nodi per eseguire i pod con possibilità di burst. GKE applica incompatibilità a questi nuovi nodi per prevenire I pod, come carichi di lavoro critici, vengono eseguiti sugli stessi nodi. Per maggiori dettagli, vedi Configura 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 di un nodo, indipendentemente dall'effettiva capacità di risorse del nodo. Se un pod viene terminati, la capacità di burstable viene ridotta dalle richieste di quel pod. La parte della capacità di burstable non in uso dai pod in esecuzione è disponibile allocare se uno dei pod deve eseguire il burst.

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

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

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 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 in grado di gestire rimossa quando Kubernetes deve recuperare memoria sul nodo.
  • Richiedi sempre memoria sufficiente per l'avvio del pod. Non fare affidamento sulla memoria di burst per soddisfare i requisiti di avvio.
  • Per evitare che i pod con possibilità di bursting che esplorino in modo coerente in multipli del loro Potenziali interruzioni delle richieste di CPU per 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 burstable come somma delle risorse richieste a tutti i pod su un nodo specifico, inclusi pod di sistema DaemonSet. Puoi ottimizzare la capacità di burstable su un nodo nelle seguenti in molti modi diversi. 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 con possibilità di burst dimostrare come funziona il bursting dei pod in GKE Autopilot cluster:

  • 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 CPU da 250 m, la capacità di burstable disponibile. Per il nodo non sono più disponibili di burstable.
  • 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 una CPU aggiuntiva di 200 m: può eseguire il burst e utilizzare 150 m di CPU, il che porta l'utilizzo totale di 250 m di CPU per il pod 2. Il pod 2 ha un limite di CPU di 250 m e non può esplodere oltre quel 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à con possibilità di burst su dal nodo, GKE esegue le seguenti azioni:

  • CPU: se l'utilizzo della CPU supera la capacità di burstable, GKE Limita l'utilizzo della CPU da parte di alcuni container in modo che tutti i container di ottenere la CPU richiesta.
  • Memoria: se la memoria utilizzata supera la capacità di cui è possibile eseguire il burst, GKE termina i container per recuperare memoria sul nodo. GKE inizia chiudendo i container che usano molte risorse con una QoS inferiore.

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 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 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. Per Ad esempio, puoi eseguire il deployment di pod con un valore PriorityClass basso. Per maggiori dettagli, vedi Esegui 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 limiti superiori alle richieste o omettendo dei limiti. Tuttavia, nei cluster standard, devi creare e configurare pool di nodi con e la capacità delle risorse appropriata per supportare il bursting. Ottenere il costo potenziale della riduzione dei pod con possibilità di burst nei cluster Standard richiede la pianificazione dei nodi e il bin-packing dei pod, in quanto paghi per le risorse di Compute Engine.

Considera quanto segue nei cluster Standard:

  • Il limite massimo di consumo di risorse che attiva Kubernetes l'eliminazione o la limitazione della CPU è la capacità di risorse allocabile 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. di pod che entrano in stato di memoria hanno quindi maggiori probabilità di essere terminate da Kubernetes eliminazione della pressione dei nodi.

Passaggi successivi