Per migliorare la stabilità dei workload, la modalità Autopilot di Google Kubernetes Engine (GKE) gestisce i valori delle richieste di risorse dei pod, come CPU, memoria o spazio di archiviazione temporaneo. Questa pagina include le seguenti informazioni, che puoi utilizzare per pianificare workload efficienti, stabili ed economicamente vantaggiosi:
- Valori predefiniti applicati da Autopilot ai pod che non specificano valori.
- Valori minimi e massimi applicati da Autopilot per le richieste di risorse.
- Come variano i valori predefiniti, minimi e massimi in base all'hardware richiesto dai pod.
Questa pagina è rivolta agli operatori e agli sviluppatori che eseguono il provisioning e la configurazione delle risorse cloud e il deployment dei workload. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti GKE.
Dovresti già avere familiarità con la gestione delle risorse Kubernetes.
Panoramica delle richieste di risorse in Autopilot
Autopilot utilizza le richieste di risorse specificate nella configurazione del workload per configurare i nodi che eseguono i workload. Autopilot applica richieste di risorse minime e massime in base alla classe di computing o alla configurazione hardware utilizzata dai workload. Se non specifichi le richieste per alcuni container, Autopilot assegna valori predefiniti per consentire l'esecuzione corretta dei container.
Quando esegui il deployment di un workload in un cluster Autopilot, GKE convalida la configurazione del workload in base ai valori minimi e massimi consentiti per la classe di computing o la configurazione hardware selezionata (ad esempio le GPU). Se le tue richieste sono inferiori al minimo, Autopilot modifica automaticamente la configurazione del workload per portare le richieste nell'intervallo consentito. Se le tue richieste superano il limite massimo, Autopilot rifiuta il workload e visualizza un messaggio di errore.
Il seguente elenco riepiloga le categorie di richieste di risorse:
- Richieste di risorse predefinite: Autopilot le aggiunge se non specifichi le tue richieste per i workload.
- Richieste di risorse minime e massime: Autopilot convalida le richieste specificate per assicurarsi che rientrino in questi limiti. Se le tue richieste non rientrano nei limiti, Autopilot modifica le richieste dei workload.
- Richieste di separazione dei workload e di durata estesa: Autopilot ha valori predefiniti e valori minimi diversi per i workload che separi l'uno dall'altro o per i pod che ricevono una protezione estesa dall'eliminazione avviata da GKE.
- Richieste di risorse per i DaemonSet: Autopilot ha valori predefiniti, minimi e massimi diversi per i container nei DaemonSet.
Come richiedere le risorse
In Autopilot, richiedi le risorse nella specifica del pod. Le risorse minime e massime supportate che puoi richiedere cambiano in base alla configurazione hardware del nodo su cui vengono eseguiti i pod. Per scoprire come richiedere configurazioni hardware specifiche, consulta le seguenti pagine:
- Scegli le classi di computing per i pod Autopilot
- Esegui il deployment dei workload GPU in Autopilot
Richieste di risorse predefinite
Se non specifichi le richieste di risorse per alcuni container in un pod, Autopilot applica i valori predefiniti. Queste impostazioni predefinite sono adatte per molti workload di dimensioni ridotte.
Inoltre, Autopilot applica le seguenti richieste di risorse predefinite, indipendentemente dalla classe di computing o dalla configurazione hardware selezionata:
Container nei DaemonSet
- CPU: 50 mCPU
- Memoria: 100 MiB
- Archiviazione temporanea: 100 MiB
Tutti gli altri container
- Archiviazione temporanea: 1 GiB
Per saperne di più sui limiti dei cluster Autopilot, consulta Quote e limiti.
Richieste predefinite per le classi di computing
Autopilot applica i seguenti valori predefiniti alle risorse non definite nella specifica dei pod per i pod eseguiti su classi di computing. Se imposti solo una delle richieste e lasci l'altra vuota, GKE utilizza il rapporto CPU:memoria definito nella sezione Richieste minime e massime per impostare la richiesta mancante su un valore conforme al rapporto.
Autopilot non applica le richieste predefinite per i pod GPU e i pod che utilizzano la classe ComputeClass Performance.
| Classe di computing | Risorsa | Richiesta predefinita |
|---|---|---|
Per uso generico (autopilot predefinito o autopilot-arm) |
CPU | 0,5 vCPU |
| Memoria | 2 GiB | |
| Bilanciato | CPU | 0,5 vCPU |
| Memoria | 2 GiB | |
| Scale out | CPU | 0,5 vCPU |
| Memoria | 2 GiB |
Richieste di risorse minime e massime
Le richieste di risorse totali richieste dalla configurazione del deployment devono rientrare nei valori minimi e massimi supportati consentiti da Autopilot. Si applicano le seguenti condizioni:
Richiesta minima per nodo: quando utilizzi il modello di fatturazione basato su pod per eseguire workload in modalità Autopilot in cluster Standard e la somma delle richieste di risorse dei pod fatturabili su un nodo è inferiore alla richiesta minima che si applica a un singolo pod, GKE aggiunge un addebito per la richiesta minima.
A causa del modo in cui Autopilot modifica le richieste di risorse dei pod, la somma delle richieste di pod fatturabili su un nodo soddisfa o supera quasi sempre questa richiesta minima per nodo.
Richieste di archiviazione temporanea:
L'archiviazione temporanea utilizza il disco di avvio della VM, a meno che ai nodi non siano collegati SSD locali.
L'hardware di computing che include SSD locali come GPU A100 (80 GB), GPU H100 (80 GB), la serie di macchine Z3 o la serie di macchine Z4D supporta una richiesta massima pari alle dimensioni dell'SSD locale meno l'overhead di sistema. Per informazioni su questo overhead di sistema, consulta Archiviazione temporanea supportata da SSD locali.
In GKE versione 1.29.3-gke.1038000 e successive, i pod della classe Performance e i pod dell'acceleratore hardware supportano una richiesta di archiviazione temporanea massima di 56 TiB, a meno che l'hardware non includa SSD locali.
In tutti gli altri pod Autopilot, indipendentemente dalla versione di GKE, la richiesta di archiviazione temporanea totale in tutti i container del pod deve essere compresa tra 10 MiB e 10 GiB, se non diversamente specificato.
Per volumi più grandi, utilizza i volumi temporanei generici, che offrono funzionalità e prestazioni equivalenti allo spazio di archiviazione temporaneo, ma con una flessibilità notevolmente maggiore, in quanto possono essere utilizzati con qualsiasi opzione di archiviazione GKE. Ad esempio, la dimensione massima di un volume temporaneo generico che utilizza
pd-balancedè 64 TiB.
Per i pod DaemonSet, le richieste di risorse minime sono le seguenti:
- Cluster che supportano il bursting: 1 mCPU per pod, 2 MiB di memoria per pod e 10 MiB di archiviazione temporanea per container nel pod.
- Cluster che non supportano il bursting: 10 mCPU per pod, 10 MiB di memoria per pod e 10 MiB di archiviazione temporanea per container nel pod.
Per verificare se il tuo cluster supporta il bursting, consulta Disponibilità del bursting in GKE.
Se il tuo cluster supporta il bursting, Autopilot non applica incrementi di 0,25 vCPU per le richieste di CPU dei pod. Se il tuo cluster non supporta il bursting, Autopilot arrotonda le richieste di CPU alla vCPU più vicina (0,25 vCPU). Per verificare se il tuo cluster supporta il bursting, consulta Disponibilità del bursting in GKE.
Il rapporto CPU:memoria deve rientrare nell'intervallo consentito per la classe di computing o la configurazione hardware selezionata. Se il rapporto CPU:memoria non rientra nell'intervallo consentito, Autopilot aumenta automaticamente la risorsa più piccola. Ad esempio, se richiedi 1 vCPU e 16 GiB di memoria (rapporto 1:16) per i pod in esecuzione nella classe
Scale-Out, Autopilot aumenta la richiesta di CPU a 4 vCPU, il che modifica il rapporto in 1:4.
Valori minimi e massimi per le classi di computing
La tabella seguente descrive il rapporto CPU/memoria minimo, massimo e consentito per ogni classe di computing supportata da Autopilot:
| Classe di computing | Rapporto CPU:memoria (vCPU:GiB) | Risorsa | Minimo | Massimo |
|---|---|---|---|---|
Per uso generico (autopilot predefinito o autopilot-arm) |
Tra 1:1 e 1:6,5 | CPU | Il valore dipende dal fatto che il cluster supporti o meno il bursting, come segue:
Per verificare se il tuo cluster supporta il bursting, consulta Disponibilità del bursting in GKE. |
30 vCPU |
| Memoria | Il valore dipende dal fatto che il cluster supporti o meno il bursting, come segue:
Per verificare se il tuo cluster supporta il bursting, consulta Disponibilità del bursting in GKE. |
110 GiB | ||
| Bilanciato | Tra 1:1 e 1:8 | CPU | 0,25 vCPU | 222 vCPU Se è selezionata una piattaforma CPU minima:
|
| Memoria | 0,5 GiB | 851 GiB Se è selezionata una piattaforma CPU minima:
|
||
| Prestazioni | N/D | CPU | Nessun numero minimo di richieste applicato |
|
| Memoria | Nessun numero minimo di richieste applicato |
|
||
| Archiviazione temporanea | Nessun numero minimo di richieste applicato |
|
||
| Scale out | Esattamente 1:4 | CPU | 0,25 vCPU |
|
| Memoria | 1 GiB |
|
Per scoprire come richiedere classi di computing nei pod Autopilot, consulta Scegli le classi di computing per i pod Autopilot.
Valori minimi e massimi per gli acceleratori
GKE non applica richieste minime di CPU, memoria o spazio di archiviazione temporaneo per i pod che utilizzano acceleratori. La tabella seguente descrive le richieste massime per ciascuna di queste risorse in base al numero e al tipo di acceleratore che utilizzi.
Se non diversamente specificato, lo spazio di archiviazione temporaneo massimo supportato è di 56 TiB.
| Tipo di acceleratore | Risorsa | Massimo |
|---|---|---|
NVIDIA B200nvidia-B200 |
CPU |
|
| Memoria |
|
|
| Archiviazione temporanea |
|
|
NVIDIA H200 (141GB)nvidia-h200-141gb |
CPU |
|
| Memoria |
|
|
| Archiviazione temporanea |
|
|
NVIDIA H100 Mega (80GB)nvidia-h100-mega-80gb |
CPU |
|
| Memoria |
|
|
| Archiviazione temporanea |
|
|
NVIDIA H100 (80GB)nvidia-h100-80gb |
CPU |
|
| Memoria |
|
|
| Archiviazione temporanea |
|
|
NVIDIA A100 (40GB)nvidia-tesla-a100 |
CPU |
La somma delle richieste di CPU di tutti i DaemonSet eseguiti su un nodo GPU A100 non deve superare 2 vCPU. |
| Memoria |
La somma delle richieste di memoria di tutti i DaemonSet eseguiti su un nodo GPU A100 non deve superare i 14 GiB. |
|
NVIDIA A100 (80GB)nvidia-a100-80gb |
CPU |
La somma delle richieste di CPU di tutti i DaemonSet eseguiti su un nodo GPU A100 (80 GB) non deve superare 2 vCPU. |
| Memoria |
La somma delle richieste di memoria di tutti i DaemonSet eseguiti su un nodo GPU A100 (80 GB) non deve superare i 14 GiB. |
|
| Archiviazione temporanea |
|
|
NVIDIA RTX PRO 6000nvidia-rtx-pro-6000
|
CPU |
|
| Memoria |
|
|
| Archiviazione temporanea |
|
|
NVIDIA L4nvidia-l4 |
CPU |
La somma delle richieste di CPU di tutti i DaemonSet eseguiti su un nodo GPU L4 non deve superare 2 vCPU. |
| Memoria |
La somma delle richieste di memoria di tutti i DaemonSet eseguiti su un nodo GPU L4 non deve superare i 14 GiB. |
|
NVIDIA Tesla T4nvidia-tesla-t4 |
CPU |
|
| Memoria |
|
|
Ironwood (TPU7x)tpu7x |
CPU |
|
| Memoria |
|
|
| Archiviazione temporanea | 56 TiB | |
TPU v6e (anteprima)tpu-v6e-slice |
CPU |
|
| Memoria |
|
|
| Archiviazione temporanea | 56 TiB | |
TPU v5etpu-v5-lite-podslice |
CPU |
|
| Memoria |
|
|
| Archiviazione temporanea | 56 TiB | |
TPU v5ptpu-v5p-slice |
CPU | 280 vCPU |
| Memoria | 448 GiB | |
| Archiviazione temporanea | 56 TiB | |
TPU v4tpu-v4-podslice |
CPU | 240 vCPU |
| Memoria | 407 GiB | |
| Archiviazione temporanea | 56 TiB |
Per scoprire come richiedere GPU nei pod Autopilot, consulta Esegui il deployment dei workload GPU in Autopilot.
Richieste di risorse per la separazione dei workload e la durata estesa
Nei seguenti scenari, Autopilot applica valori più elevati per le richieste di risorse predefinite e minime:
- Utilizzi una regola di priorità
podFamilyin qualsiasi ComputeClass Autopilot personalizzata che non sia l'impostazione predefinita a livello di cluster. - Esegui il deployment di workload che soddisfano entrambi i seguenti criteri:
- Utilizza una delle seguenti configurazioni di computing:
- La piattaforma di computing ottimizzata per i container predefinita nei cluster Autopilot.
- Qualsiasi ComputeClass Autopilot integrata.
podFamilyregole di priorità in una classe ComputeClass Autopilot personalizzata che è anche l'impostazione predefinita a livello di cluster.- Le classi di computing
BalancedoScale-Outnei cluster Autopilot.
- Manipola il comportamento di pianificazione ed espulsione di Kubernetes in uno dei seguenti modi:
- Utilizza la separazione dei workload per assicurarti che determinati pod vengano posizionati solo su nodi specifici.
- Utilizza l'anti-affinità dei pod per impedire la co-localizzazione dei pod sullo stesso nodo.
- Utilizza un'annotazione per estendere il tempo di esecuzione dei pod Autopilot, impedendo l'espulsione a causa di upgrade automatici dei nodi ed eventi di scale down per un massimo di sette giorni.
- Utilizza una delle seguenti configurazioni di computing:
Per impostazione predefinita, se le richieste di risorse sono inferiori al valore minimo consentito, Autopilot le aumenta per soddisfare il minimo. L'eccezione a questo comportamento è l'anti-affinità pod, in cui Autopilot rifiuta il pod con un messaggio di errore.
La seguente tabella descrive le richieste predefinite e le richieste di risorse minime che puoi specificare in questi scenari:
| Configurazione | Predefinito | Minimo |
|---|---|---|
Pod che modificano il comportamento di pianificazione o espulsione e utilizzano una delle seguenti configurazioni:
|
|
|
Pod che utilizzano regole podFamily in ComputeClass personalizzate non predefinite |
|
|
Pod che modificano il comportamento di pianificazione o espulsione e utilizzano la classe di computing Balanced nei cluster Autopilot |
|
|
Pod che modificano il comportamento di pianificazione o espulsione e utilizzano la classe di computing Scale-Out nei cluster Autopilot |
|
|
Container inizializzazione
I container init vengono eseguiti in sequenza e tutti i container init devono terminare l'esecuzione prima che i container dell'applicazione possano avviarsi. Nei cluster Autopilot, se non specifichi richieste di CPU o memoria per i container init o se imposti esplicitamente le richieste su 0, Autopilot modifica i pod durante la creazione per aggiungere richieste di risorse a ogni container init. Le richieste assegnate a ogni init container sono uguali alla somma delle richieste per tutti i container dell'applicazione nel pod. Questo è il comportamento predefinito.
Questo comportamento è diverso da quello dei cluster Standard, in cui gli init container utilizzano le risorse non allocate disponibili sul nodo su cui è pianificato il pod.
Allocazione automatica delle risorse per i container init
L'allocazione automatica delle risorse per i container init avviene al momento della creazione del pod. Ti suggeriamo di non specificare manualmente le richieste di risorse per i container init nei cluster Autopilot, in modo che ogni container riceva per impostazione predefinita le risorse complete disponibili per il pod.
Se modifichi le richieste di risorse dei container non init nel pod dopo la creazione, Autopilot non modifica automaticamente le richieste di risorse dei container init. Di conseguenza, potresti notare addebiti che non sono coerenti con l'utilizzo effettivo delle risorse del pod. La fattura si basa sulla richiesta di risorse effettiva del pod, che corrisponde al valore maggiore tra i seguenti:
- La richiesta di risorse più grande di qualsiasi singolo container init nel pod.
- La somma delle richieste per tutti i container dell'applicazione nel pod.
Per saperne di più, consulta Gestione automatica delle risorse in Autopilot.
Allocazione manuale delle risorse per i container init
Se devi modificare le richieste di risorse esistenti per i container dell'applicazione per gestire costi e risorse, ti consigliamo di eseguire una delle seguenti operazioni per modificare le richieste dei container init:
- Aggiorna manualmente le richieste di risorse per il container init in modo che corrispondano alle nuove richieste totali sul pod. Quando specifichi manualmente le richieste di risorse, tieni presente quanto segue:
- Le richieste inferiori alle risorse totali del pod possono limitare l'init container.
- Le richieste superiori alle risorse totali del pod possono aumentare i costi.
- Rimuovi le richieste di risorse per consentire ad Autopilot di ricalcolarle. Autopilot riassegnerà per impostazione predefinita le risorse a ogni container init in base alle richieste di risorse totali correnti richieste da tutti i container dell'applicazione nel pod.
Impostazione dei limiti delle risorse in Autopilot
Kubernetes ti consente di impostare sia requests che limits per le risorse nella specifica del pod. Il comportamento dei pod cambia a seconda che i limits siano diversi dai requests, come descritto nella tabella seguente:
| Valori impostati | Comportamento di Autopilot |
|---|---|
requests uguale a limits |
I pod utilizzano la classe QoS Guaranteed.
|
requests impostato, limits non impostato |
Il comportamento dipende dal fatto che il cluster supporti o meno il bursting, come segue:
Per verificare se il tuo cluster supporta il bursting, consulta Disponibilità del bursting in GKE. |
requests non impostato, limits impostato |
Autopilot imposta requests sul valore
di limits, che è il comportamento predefinito di Kubernetes.
Prima: resources:
limits:
cpu: "400m"Dopo: resources:
requests:
cpu: "400m"
limits:
cpu: "400m" |
requests in meno rispetto a limits |
Il comportamento dipende dal fatto che il cluster supporti o meno il bursting, come segue:
Per verificare se il tuo cluster supporta il bursting, consulta Disponibilità del bursting in GKE. |
requests maggiore di limits |
Autopilot imposta requests sul valore di limits.
Prima: resources:
requests:
cpu: "450m"
limits:
cpu: "400m"Dopo: resources:
requests:
cpu: "400m"
limits:
cpu: "400m" |
requests non impostato, limits non impostato |
Autopilot imposta Il comportamento di
Per verificare se il tuo cluster supporta il bursting, consulta Disponibilità del bursting in GKE. |
Nella maggior parte dei casi, imposta richieste di risorse adeguate e limiti uguali per i tuoi workload.
Per i workload che richiedono temporaneamente più risorse rispetto allo stato stabile, ad esempio durante l'avvio o durante i periodi di traffico più elevato, imposta limiti superiori alle richieste per consentire il bursting dei pod. Per maggiori dettagli, consulta Configura il bursting dei pod in GKE.
Gestione automatica delle risorse in Autopilot
Se le richieste di risorse specificate per i workload non rientrano negli intervalli consentiti o se non richiedi risorse per alcuni container, Autopilot modifica la configurazione del workload per rispettare i limiti consentiti. Autopilot calcola i rapporti delle risorse e i requisiti di scale up delle risorse dopo aver applicato i valori predefiniti ai container senza richieste specificate.
- Richieste mancanti: se non richiedi risorse in alcuni container, Autopilot applica le richieste predefinite per la classe di computing o la configurazione hardware.
- Rapporto CPU:memoria: Autopilot esegue lo scale up della risorsa più piccola per portare il rapporto entro l'intervallo consentito.
- Archiviazione temporanea: Autopilot modifica le richieste di archiviazione temporanea per soddisfare la quantità minima richiesta da ogni container. Il valore cumulativo delle richieste di archiviazione in tutti i container non può essere superiore al valore massimo consentito. Prima della versione 1.28.6-gke.1317000, Autopilot fa lo scale down dello spazio di archiviazione temporaneo richiesto se il valore supera il massimo. Nella versione 1.28.6-gke.1317000 e successive, Autopilot rifiuta il workload.
- Richieste inferiori ai minimi: se richiedi meno risorse rispetto al minimo consentito per la configurazione hardware selezionata, Autopilot modifica automaticamente il pod per richiedere almeno il valore minimo delle risorse.
Per impostazione predefinita, quando Autopilot esegue la scalabilità automatica di una risorsa per soddisfare un valore minimo o predefinito della risorsa, GKE alloca la capacità aggiuntiva al primo container nel manifest del pod. In GKE versione 1.27.2-gke.2200 e successive, puoi indicare a GKE di allocare le risorse aggiuntive a un container specifico aggiungendo quanto segue al campo annotations nel manifest del pod:
autopilot.gke.io/primary-container: "CONTAINER_NAME"
Sostituisci CONTAINER_NAME con il nome del container.
Esempi di modifica delle risorse
Lo scenario di esempio seguente mostra come Autopilot modifica la configurazione del workload per soddisfare i requisiti dei pod e dei container in esecuzione.
Container singolo con < 0,05 vCPU
| Numero del container | Richiesta originale | Richiesta modificata |
|---|---|---|
| 1 |
CPU: 30 mCPU Memoria: 0,5 GiB Spazio di archiviazione temporaneo: 10 MiB |
CPU: 50 mCPU Memoria: 0,5 GiB Spazio di archiviazione temporaneo: 10 MiB |
Più container con CPU totale < 0,05 vCPU
| Numero del container | Richieste originali | Richieste modificate |
|---|---|---|
| 1 | CPU: 10 mCPU Memoria: 0,5 GiB Archiviazione temporanea: 10 MiB |
CPU: 30 mCPU Memoria: 0,5 GiB Spazio di archiviazione temporaneo: 10 MiB |
| 2 | CPU: 10 mCPU Memoria: 0,5 GiB Archiviazione temporanea: 10 MiB |
CPU: 10 mCPU Memoria: 0,5 GiB Archiviazione temporanea: 10 MiB |
| 3 | CPU: 10 mvCPU Memoria: 0,5 GiB Spazio di archiviazione temporaneo: 10 MiB |
CPU: 10 mCPU Memoria: 0,5 GiB Archiviazione temporanea: 10 MiB |
| Risorse totali dei pod | CPU: 50 mCPU Memoria: 1,5 GiB Archiviazione temporanea: 30 MiB |
Container singolo con memoria troppo bassa per la CPU richiesta
In questo esempio, la memoria è troppo bassa per la quantità di CPU (minimo 1 vCPU:1 GiB). Il rapporto minimo consentito tra CPU e memoria è 1:1. Se il rapporto è inferiore, la richiesta di memoria viene aumentata.
| Numero del container | Richiesta originale | Richiesta modificata |
|---|---|---|
| 1 | CPU: 4 vCPU Memoria: 1 GiB Spazio di archiviazione temporaneo: 10 MiB |
CPU: 4 vCPU Memoria: 4 GiB Spazio di archiviazione temporaneo: 10 MiB |
| Risorse totali dei pod | CPU: 4 vCPU Memoria: 4 GiB Spazio di archiviazione temporaneo: 10 MiB |
Passaggi successivi
- Scopri come configurare il bursting dei pod in GKE.
- Scopri come scegliere le classi di computing per i pod Autopilot.
- Scopri come accelerare l'avvio delle applicazioni utilizzando l'avvio della CPU.