Configurare il bursting dei pod in GKE

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 che utilizzano temporaneamente più capacità di calcolo sul nodo rispetto a quanto richiesto inizialmente.

Kubernetes ti 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'intero tempo di esecuzione. 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 situazioni, puoi impostare i limiti delle risorse per il tuo carico di lavoro 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 ulteriori informazioni sul funzionamento di questo processo in GKE, consulta Capacità espandibile in GKE in questa pagina.

Vantaggi dell'aumento del numero di pod

L'aumento improvviso è utile quando i pod richiedono 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 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 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.

L'aumento temporaneo della richiesta ti consente di richiedere solo le risorse necessarie al pod per la maggior parte del suo tempo di esecuzione, garantendo al contempo che il pod possa consumare più risorse, se necessario. I vantaggi della pubblicazione in blocco includono:

  • Costi di gestione inferiori: non è necessario richiedere il picco previsto del consumo di risorse del carico di lavoro. 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 gestione sono inferiori.
  • Utilizzo più efficiente delle risorse: eviti la capacità di calcolo inutilizzata perché i pod utilizzano la capacità inutilizzata. I tuoi carichi di lavoro hanno maggiori probabilità di utilizzare 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 avviarsi più rapidamente durante gli eventi di scale up.

Quando non utilizzare la suddivisione

Kubernetes assegna la classe Burstable Quality of Service (QoS) ai pod che specificano limiti di risorse superiori alle loro richieste. Burstable I pod QoS hanno maggiori probabilità di essere eliminati quando Kubernetes deve recuperare le 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à, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.
  • Assicurati di avere un cluster GKE Autopilot che esegui la versione 1.30.2-gke.1394000 o successive o qualsiasi versione di un cluster GKE Standard. Per creare un nuovo cluster, consulta Creare un cluster Autopilot.

Disponibilità del picco in GKE

I carichi di lavoro possono aumentare nelle seguenti situazioni:

Disponibilità per picchi di domanda
Modalità GKE Autopilot

I seguenti tipi di pod possono essere sottoposti a bursting in qualsiasi versione GKE che supporta l'hardware richiesto dai pod:

Per tutti gli altri carichi di lavoro, l'esplosione è disponibile se il clustersoddisfa entrambe le seguenti condizioni:

  • Il cluster è in esecuzione su cgroupv2. I cluster creati con GKE 1.26 o versioni successive o di cui è stata eseguita la migrazione a cgroupv2 soddisfano questa condizione. Consulta la sezione Controllare la modalità cgroup per determinare la versione cgroup corrente ed eseguire la migrazione, se necessario.
  • Il cluster esegue GKE versione 1.30.2-gke.1394000 o successive
Modalità GKE Standard I pod possono aumentare in qualsiasi versione di GKE.

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 alla versione del piano di controllo 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 del piano di controllo:

    1. Verifica 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.

    2. Avvia manualmente un upgrade del piano di controllo alla stessa versione già in uso dal cluster. Per le istruzioni, consulta Eseguire l'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

  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 attivare l'esplosione:

    • resources.requests: le risorse necessarie al funzionamento del contenitore. Imposta questo valore sulla capacità di cui avrà bisogno il contenitore in stato stazionario.
    • resources.limits: la capacità massima di risorse che il contenitore può utilizzare. L'impostazione di limiti superiori alle richieste consente ai pod di aumentare fino al limite specificato, se questa capacità è disponibile sul nodo. Se ometti questo campo, i pod possono aumentare fino alla capacità di picco disponibile 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 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 espandibili. GKE applica le 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 carichi di lavoro. Per maggiori dettagli, consulta Configurare la separazione dei carichi di lavoro 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à espandibile in GKE

Per facilitare il bursting dei pod, GKE calcola la capacità espandibile per ogni nodo di 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 allocabili 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 terminato, la capacità espandibile si riduce in base alle richieste del pod. La parte della capacità espandibile non in uso dai pod in esecuzione è disponibile per l'allocazione se uno dei pod deve essere espanso.

    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à di 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 uguali ai limiti per tutti i pod che forniscono funzionalità critiche nel tuo ambiente. In questo modo, i pod ricevono la classe Guaranteed Qualità del servizio (QoS) di Kubernetes.
  • Assicurati di configurare l'aumento della memoria solo sui pod che possono essere espulsi quando Kubernetes deve recuperare la 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, l'esplosione è opportunistica e non è garantita.

  • Per aumentare la capacità di picco sui nodi per carichi di lavoro specifici, utilizza Pod Affinity per raggruppare pod specifici sullo stesso nodo.
  • Per assicurarti che una capacità espandibile 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 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 di CPU. Il pod 2 utilizza 100 milioni di CPU per l'esecuzione.

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). Ogni pod utilizza solo 100 m di CPU per l'esecuzione, il che significa che il nodo ha una capacità di picco disponibile rimanente di 250 m.

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

  • Il pod 1 ha bisogno di 300 milioni di CPU aggiuntive: può eseguire lo bursting e utilizzare 250 milioni di CPU, ovvero la capacità di bursting disponibile. Il nodo non ha più capacità aggiuntiva disponibile.
  • Il pod 2 ha bisogno di 150 MB di CPU aggiuntivi: può aumentare e utilizzare altri 150 MB di CPU. Il nodo ha quindi 100 milioni di CPU di capacità espandibile rimanente.
  • 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 milioni e non può superare questo 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 del 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.

Utilizzare 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à più rapida dei pod durante eventi di traffico elevato futuri, come le offerte lampo del negozio online. Altri pod sullo stesso nodo possono utilizzare questa capacità riservata inutilizzata in modo che non rimanga inattiva nel periodo precedente all'evento con 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.

Pod bursting nei cluster GKE Standard

I cluster GKE Standard supportano anche il bursting dei pod impostando i limiti più elevati delle richieste o omettendo i 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 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. Pertanto, i pod che consumano molta memoria hanno maggiori probabilità di essere terminati da Kubernetes tramite l'espulsione per pressione del nodo.

Passaggi successivi