Questa pagina è stata tradotta dall'API Cloud Translation.

Configurare il bursting dei pod in GKE

Autopilot Standard

Questa pagina mostra come configurare i pod per il bursting della capacità inutilizzata disponibile sui nodi di Google Kubernetes Engine (GKE).

Cos'è lo scoppio?

Bursting descrive l'azione dei pod che utilizzano temporaneamente 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. Puoi impostare queste richieste nel manifest del pod. Lo scheduler Kubernetes posiziona i pod su nodi con una capacità sufficiente per soddisfare le 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 molta CPU 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 carico di lavoro su un valore superiore a quello richiesto dalla risorsa o lasciare i limiti non impostati. GKE consente al carico di lavoro di utilizzare temporaneamente più risorse di quelle specificate nelle richieste, se disponibile.

Per maggiori informazioni su come funziona questo processo in GKE, consulta Come funziona il bursting 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 ai picchi di utilizzo delle risorse. Ecco alcuni scenari di esempio:

Hai gruppi di carichi di lavoro che sono spesso inattivi e inviano un numero ridotto di richieste al secondo, ma occasionalmente presentano 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.

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 i seguenti:

Costi di esecuzione ridotti: non è necessario richiedere il picco previsto del consumo di risorse del carico di lavoro. Le richieste possono riguardare i valori dello stato stazionario più bassi. In Autopilot, paghi la somma delle richieste di risorse dei pod, quindi i costi di esecuzione sono inferiori.
Utilizzo più efficiente delle risorse: eviti capacità di calcolo inattiva, poiché i tuoi pod raggiungono il burst in una capacità inutilizzata. È più probabile che i carichi di lavoro utilizzino tutte le risorse a pagamento.
Prestazioni migliorate: i pod possono utilizzare risorse aggiuntive a seconda delle esigenze per ridurre i tempi di elaborazione delle richieste in entrata o per avviarsi più rapidamente durante gli eventi di scale up.

Quando non utilizzare la sequenza di foto a raffica

Kubernetes assegna la classe Burstable Qualità del servizio (QoS) ai pod che specificano limiti delle risorse superiori rispetto alle loro richieste. Burstable I pod QoS hanno maggiori probabilità di essere rimossi quando Kubernetes deve recuperare risorse sul nodo. Per ulteriori informazioni, consulta 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

Se vuoi utilizzare Google Cloud CLI per questa attività, installa e initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.
Nota: per le installazioni esistenti dell'interfaccia a riga di comando gcloud, assicurati di impostare le proprietà compute/region e compute/zone. Impostando le località predefinite, puoi evitare errori nellgcloud CLI come segue: One of [--zone, --region] must be supplied: Please specify location.

Assicurati di avere un cluster GKE Autopilot che esegue la versione 1.29.2-gke.1060000 o successive, o una 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 essere sottoposti a burst nelle seguenti situazioni:

Disponibilità del bursting
Modalità GKE Autopilot	I pod che utilizzano la classe di computing Performance o la classe di computing Accelerator possono eseguire il bursting in qualsiasi versione di GKE che supporti quella classe di computing. 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 condizioni seguenti: Hai creato inizialmente 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.

Disponibilità del bursting

Modalità GKE Autopilot

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

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 condizioni seguenti:

Hai creato inizialmente 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 originariamente creati con una versione precedente alla 1.26 e per i quali è stato eseguito l'upgrade alla versione 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 versione 1.26 o successiva.

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

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 per il container in stato stabile.
- resources.limits: la capacità massima di 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 questa capacità è disponibile sul nodo. Se ometti questo campo, i pod possono eseguire il bursting fino alla capacità con 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. Indica a GKE di creare nuovi nodi per eseguire i pod con possibilità di burst. GKE applica incompatibilità a questi nuovi nodi per impedire l'esecuzione di altri pod, come i carichi di lavoro critici, sugli stessi nodi. Per maggiori dettagli, consulta Configurare la separazione dei carichi di lavoro in GKE.
Esegui il deployment del carico di lavoro:
```
kubectl apply -f burstable-deployment.yaml
```
L'avvio del carico di lavoro potrebbe richiedere alcuni minuti.

Controlla la classe QoS di un pod:

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

L'output è il seguente:

QoS Class: Burstable

Capacità bursabile 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 burst si riduce in base alle richieste di quel pod. La parte della capacità di burst che non è utilizzata dai pod in esecuzione è disponibile per allocare se uno dei pod deve eseguire il bursting.

Autopilot aggiunge anche un buffer predefinito alla capacità con burst in modo che i pod di sistema sul nodo che eseguono il bursting oltre le 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

Usa le seguenti pratiche per 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. In questo modo, i pod ricevono la classe QoS (Qualità del servizio) di Kubernetes Guaranteed.
Assicurati di configurare il bursting della memoria solo sui pod in grado di gestire la rimozione quando Kubernetes deve recuperare la 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 possibilità di burst, che eseguono burst in modo coerente in molteplici richieste della CPU, potrebbero interrompere i carichi di lavoro critici, utilizza la separazione dei carichi di lavoro per evitare di posizionare questi pod accanto a quelli critici.

Ottimizza la capacità di burstable nei nodi Autopilot

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

Per aumentare la capacità di possibilità di bursting sui nodi per carichi di lavoro specifici, utilizza l'affinità pod per collocare pod specifici sullo stesso nodo.
Per assicurarti che una specifica capacità di cui è possibile eseguire il burst sia sempre disponibile su ogni nodo, crea dei DaemonSets da eseguire su tutti i nodi del cluster.

Esempio di come funziona la serie di foto a raffica

Questa sezione utilizza un deployment di esempio con i seguenti pod con possibilità di burst 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. L'esecuzione del pod 1 utilizza 100 m di CPU.
Il pod 2 richiede 200 metri di CPU e ha un limite di 250 metri di CPU. L'esecuzione del pod 2 utilizza 100 m di CPU.

Entrambi i pod vengono eseguiti sullo stesso nodo. La capacità totale di cui è possibile eseguire il burst sul nodo è 450 m di 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 per il bursting rimanente di 250 m.

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

Il pod 1 richiede 300 m di CPU in più: può eseguire il bursting e utilizzare 250 m di CPU, ovvero la capacità disponibile per il bursting. Il nodo non ha più capacità di bursting disponibile.
Il Pod 2 necessita di una CPU aggiuntiva di 150 m: può bursting e utilizzare 150 m di CPU in più. A questo punto, il nodo ha 100 m di CPU rimanenti di capacità disponibile per il burst.
Il Pod 2 ha bisogno di 200 m di CPU in più: 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ò eseguire burs oltre questo limite.

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

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

CPU: se l'utilizzo della CPU supera la capacità di bursting, 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à per il burst, GKE termina i container per recuperare memoria sul nodo. Per prima cosa, GKE termina i container a utilizzo intensivo di risorse nei pod con un QoS più basso.

Ti consigliamo di richiedere sempre memoria sufficiente per le normali operazioni del pod. Se un container ha una dipendenza dal bursting della memoria per funzionare normalmente, potrebbe arrestarsi ripetutamente in modo anomalo 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 riservare capacità di calcolo extra per una scalabilità più rapida dei pod durante eventi futuri a traffico elevato come le vendite lampo del negozio online. Altri pod sullo stesso nodo possono eseguire il burst in questa capacità riservata inutilizzata in modo che la capacità non sia 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 con 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 limiti superiori a quelli delle richieste oppure omettendo i limiti. Tuttavia, nei cluster Standard, devi creare e configurare pool di nodi con la 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, dato che paghi per le VM di Compute Engine sottostanti.

Nei cluster Standard, considera quanto segue:

Il limite massimo di consumo di risorse che attiva l'eliminazione o la limitazione della CPU da parte di Kubernetes è 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 rimozione di Kubernetes perché GKE non limita automaticamente il consumo delle risorse se non specifichi i limiti. Pertanto, è più probabile che i pod che eseguono il bursting in memoria vengano arrestati dall'eliminazione della pressione dei nodi di Kubernetes.