Per migliorare la stabilità del workload, la modalità Google Kubernetes Engine (GKE) Autopilot 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 carichi di lavoro efficienti, stabili ed economici:
- Valori predefiniti che Autopilot applica ai pod che non specificano valori.
- Valori minimo e massimo 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 a operatori e sviluppatori che eseguono il provisioning e la configurazione delle risorse cloud e il deployment dei carichi di lavoro. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta Ruoli e attività comuni degli utenti GKE. Google Cloud
Dovresti già avere familiarità con la gestione delle risorse di 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 calcolo o alla configurazione hardware utilizzata dai tuoi carichi di lavoro. Se non specifichi le richieste per alcuni container, Autopilot assegna valori predefiniti per consentire a questi container di essere eseguiti correttamente.
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 selezionata o per la configurazione hardware (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 valore massimo, Autopilot rifiuta il carico di lavoro 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 del workload.
- Separazione dei workload e richieste di durata estesa: Autopilot ha valori predefiniti diversi e valori minimi diversi per i workload che separi tra loro o per i pod che ricevono una protezione estesa dall'espulsione avviata da GKE.
- Richieste di risorse per DaemonSet: Autopilot ha valori predefiniti, minimi e massimi diversi per i container in DaemonSet.
Come richiedere 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:
- Scegliere le classi di computing per i pod Autopilot
- Esegui il deployment dei carichi di lavoro GPU in Autopilot
Richieste di risorse predefinite
Se non specifichi richieste di risorse per alcuni container in un pod, Autopilot applica i valori predefiniti. Questi valori predefiniti sono adatti a molti workload più piccoli.
Inoltre, Autopilot applica le seguenti richieste di risorse predefinite indipendentemente dalla classe di computing o dalla configurazione hardware selezionata:
Container in DaemonSet
- CPU: 50 mCPU
- Memoria: 100 MiB
- Spazio di archiviazione temporanea: 100 MiB
Tutti gli altri contenitori
- Archiviazione temporanea: 1 GiB
Per ulteriori informazioni 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 del pod per i pod eseguiti nelle 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.
| Classe di computing | Risorsa | Richiesta predefinita |
|---|---|---|
| Per uso generico (impostazione predefinita) | CPU | 0,5 vCPU |
| Memoria | 2 GB | |
| Acceleratore | Nessuna richiesta predefinita applicata. | |
| Bilanciato | CPU | 0,5 vCPU |
| Memoria | 2 GB | |
| Prestazioni | Nessuna richiesta predefinita applicata. | |
| Scale out | CPU | 0,5 vCPU |
| Memoria | 2 GB | |
Richieste di risorse minime e massime
Le risorse totali richieste dalla configurazione di deployment devono rientrare nei valori minimi e massimi supportati consentiti da Autopilot. Si applicano le seguenti condizioni:
Richieste di spazio di archiviazione temporanea:
Lo spazio di archiviazione temporanea utilizza il disco di avvio della VM, a meno che ai nodi non siano collegati dischi SSD locali.
L'hardware di calcolo che include SSD locali come GPU A100 (80 GB), GPU H100 (80 GB) o la serie di macchine Z3 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 di prestazioni e i pod dell'acceleratore hardware supportano una richiesta di spazio di archiviazione temporaneo massimo 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 totale di spazio di archiviazione temporaneo 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 effimeri generici, che forniscono funzionalità e prestazioni equivalenti all'archiviazione effimera, ma con una flessibilità notevolmente maggiore, in quanto possono essere utilizzati con qualsiasi opzione di archiviazione GKE. Ad esempio, la dimensione massima per un volume effimero generico che utilizza
pd-balancedè 64 TiB.
Per i pod DaemonSet, le richieste minime di risorse sono le seguenti:
- Cluster che supportano il bursting: 1 mCPU per pod, 2 MiB di memoria per pod e 10 MiB di spazio 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 spazio di archiviazione temporanea per container nel pod.
Per verificare se il tuo cluster supporta il bursting, consulta Disponibilità del bursting in GKE.
Se il cluster supporta il bursting, Autopilot non applica incrementi di 0,25 vCPU per le richieste di CPU dei pod. Se il cluster non supporta il bursting, Autopilot arrotonda le richieste di CPU al valore di vCPU più vicino a 0,25. 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 calcolo 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 sulla 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 calcolo supportata da Autopilot:
| Classe di computing | Rapporto CPU:memoria (vCPU:GiB) | Risorsa | Minimo | Massimo |
|---|---|---|---|---|
| Per uso generico (impostazione predefinita) | Tra 1:1 e 1:6,5 | CPU | Il valore dipende dal fatto che il cluster supporti 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 il bursting, come segue:
Per verificare se il tuo cluster supporta il bursting, consulta Disponibilità del bursting in GKE. |
110 GiB | ||
| Acceleratore | Consulta Valori minimi e massimi per gli acceleratori. | |||
| Bilanciato | Tra 1:1 e 1:8 | CPU | 0,25 vCPU | 222 vCPU Se è selezionata la piattaforma CPU minima:
|
| Memoria | 0,5 GiB | 851 GiB Se è selezionata la 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 GB |
|
||
Per scoprire come richiedere classi di computing nei tuoi pod Autopilot, consulta Scegliere 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 utilizzato.
Se non specificato, lo spazio di archiviazione temporaneo massimo supportato è 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 in esecuzione su un nodo GPU A100 non deve superare 2 vCPU. |
| Memoria |
La somma delle richieste di memoria di tutti i DaemonSet in esecuzione 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 in esecuzione su un nodo GPU A100 (80 GB) non deve superare i 14 GiB. |
|
| 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 in esecuzione su un nodo GPU L4 non deve superare 14 GiB. |
|
NVIDIA Tesla T4nvidia-tesla-t4 |
CPU |
|
| Memoria |
|
|
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 tuoi pod Autopilot, consulta la sezione Esegui il deployment dei carichi di lavoro GPU in Autopilot.
Richieste di risorse per la separazione dei workload e la durata estesa
Autopilot ti consente di manipolare la pianificazione e l'espulsione di Kubernetes utilizzando metodi come i seguenti:
- Utilizza incompatibilità e tolleranze e selettori di nodi per garantire che determinati pod vengano posizionati solo su nodi specifici. Per maggiori dettagli, vedi Configurare la separazione dei workload in GKE.
- Utilizza Pod anti-affinity per impedire ai pod di trovarsi sullo stesso nodo. Le richieste di risorse predefinite e minime per i workload che utilizzano questi metodi per controllare il comportamento di pianificazione sono superiori rispetto a quelle per i workload che non li utilizzano.
- Utilizza un'annotazione per proteggere i pod dall'espulsione causata da eventi di riduzione della scalabilità e aggiornamenti automatici dei nodi per un massimo di sette giorni. Per maggiori dettagli, vedi Estendi la durata di esecuzione dei pod Autopilot.
Se le richieste specificate sono inferiori ai valori minimi, il comportamento di Autopilot cambia in base al metodo utilizzato, come segue:
- Taint, tolleranze, selettori e pod di durata estesa: Autopilot modifica i pod per aumentare le richieste durante la pianificazione dei pod.
- Anti-affinità pod: Autopilot rifiuta il pod e visualizza un messaggio di errore.
La seguente tabella descrive le richieste predefinite e le richieste di risorse minime che puoi specificare. Se una configurazione o una classe di computing non è presente in questa tabella, Autopilot non applica valori minimi o predefiniti speciali.
| Classe di computing | Risorsa | Predefinito | Minimo |
|---|---|---|---|
| Per uso generico | CPU | 0,5 vCPU | 0,5 vCPU |
| Memoria | 2 GB | 0,5 GiB | |
| Bilanciato | CPU | 2 vCPU | 1 vCPU |
| Memoria | 8 GB | 4 GB | |
| Scale out | CPU | 0,5 vCPU | 0,5 vCPU |
| Memoria | 2 GB | 2 GB |
Container inizializzazione
I container
init
vengono eseguiti in sequenza e tutti devono terminare l'esecuzione prima che possano essere avviati i container
dell'applicazione. Nei cluster Autopilot, se non specifichi richieste di CPU o memoria per i container init o 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 dai cluster standard, in cui i container init utilizzano qualsiasi risorsa non allocata disponibile 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 durante la creazione del pod. Ti consigliamo di non specificare manualmente le richieste di risorse per i container init nei cluster Autopilot, in modo che ogni container riceva per impostazione predefinita tutte le risorse disponibili per il pod.
Se modifichi le richieste di risorse dei container non init nel pod dopo la creazione, Autopilot non regola automaticamente le richieste di risorse dei container init. Di conseguenza, potresti notare addebiti non coerenti con l'utilizzo effettivo delle risorse del pod. La fattura si basa sulla richiesta di risorse effettiva del pod, ovvero il valore più alto tra i seguenti:
- La richiesta di risorse più grande di qualsiasi singolo container di inizializzazione nel pod.
- La somma delle richieste per tutti i container dell'applicazione nel pod.
Per saperne di più, vedi 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. Tieni presente
quanto segue quando specifichi manualmente le richieste di risorse:
- Le richieste inferiori alle risorse totali del pod possono vincolare il container init.
- Le richieste superiori alle risorse totali del pod possono aumentare i costi.
- Rimuovi le richieste di risorse per consentire ad Autopilot di ricalcolarle. Per impostazione predefinita, Autopilot riassegna le risorse a ogni container init in base alle risorse totali attuali richieste da tutti i container dell'applicazione nel pod.
Impostazione dei limiti delle risorse in Autopilot
Kubernetes consente di impostare sia requests sia limits per le risorse nella specifica del pod. Il comportamento dei tuoi Pod cambia a seconda che i tuoi
limits siano diversi dai tuoi 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 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 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 carichi di lavoro.
Per i carichi di lavoro che hanno temporaneamente bisogno di più risorse rispetto al loro stato stazionario, ad esempio durante l'avvio o durante i periodi di traffico più elevato, imposta i limiti più alti delle richieste per consentire ai pod di eseguire il burst. Per maggiori dettagli, vedi Configurare l'utilizzo eccessivo dei pod in GKE.
Gestione automatica delle risorse in Autopilot
Se le richieste di risorse specificate per i tuoi carichi di lavoro non rientrano negli intervalli consentiti o se non richiedi risorse per alcuni container, Autopilot modifica la configurazione del carico di lavoro per rispettare i limiti consentiti. Autopilot calcola i rapporti tra le risorse e i requisiti di scalabilità delle risorse dopo aver applicato i valori predefiniti ai container senza alcuna richiesta specificata.
- 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 aumenta la risorsa più piccola per portare il rapporto nell'intervallo consentito.
- Spazio di archiviazione temporaneo:Autopilot modifica le richieste di spazio di archiviazione temporaneo per soddisfare la quantità minima richiesta da ogni container. Il valore cumulativo delle richieste di archiviazione in tutti i container non può superare il valore massimo consentito. Prima della versione 1.28.6-gke.1317000, Autopilot riduce lo spazio di archiviazione temporaneo richiesto se il valore supera il massimo. Nella versione 1.28.6-gke.1317000 e successive, Autopilot rifiuta il carico di lavoro.
- Richieste inferiori ai valori minimi: se richiedi meno risorse del 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 aumenta automaticamente le risorse per soddisfare
un valore minimo o predefinito delle risorse, 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 carico di lavoro per soddisfare i requisiti dei pod e dei container in esecuzione.
Singolo container 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 Spazio di archiviazione temporaneo: 10 MiB |
CPU: 30 mCPU Memoria: 0,5 GiB Spazio di archiviazione temporaneo: 10 MiB |
| 2 | CPU: 10 mCPU Memoria: 0,5 GiB Spazio di archiviazione temporaneo: 10 MiB |
CPU: 10 mCPU Memoria: 0,5 GiB Spazio di archiviazione temporaneo: 10 MiB |
| 3 | CPU: 10 mvCPU Memoria: 0,5 GiB Spazio di archiviazione temporaneo: 10 MiB |
CPU: 10 mCPU Memoria: 0,5 GiB Spazio di archiviazione temporaneo: 10 MiB |
| Risorse totali del pod | CPU: 50 mCPU Memoria: 1,5 GiB Spazio di archiviazione temporaneo: 30 MiB |
Singolo container con memoria troppo bassa per la CPU richiesta
In questo esempio, la memoria è troppo bassa per la quantità di CPU (1 vCPU:1 GiB minimo). 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 effimero: 10 MiB |
| Risorse totali del pod | CPU: 4 vCPU Memoria: 4 GiB Spazio di archiviazione effimero: 10 MiB |
Passaggi successivi
- Scopri come selezionare le classi di computing nei tuoi carichi di lavoro Autopilot.
- Scopri di più sulle classi di computing Autopilot supportate.
- Scopri come selezionare le GPU nei tuoi pod Autopilot.