In questa pagina vengono descritte le risorse massime, minime e predefinite richieste che puoi specificare per Google Kubernetes Engine (GKE) i carichi di lavoro Autopilot e le modifiche automatiche per mantenere la stabilità del carico di lavoro.
Panoramica delle richieste di risorse in Autopilot
Autopilot utilizza le richieste di risorse specificate nel carico di lavoro per configurare i nodi che eseguono i carichi di lavoro. Autopilot applica il numero minimo e massimo di richieste di risorse in base alla classe di computing o della configurazione hardware utilizzata dai carichi di lavoro. Se non specifichi le richieste per alcuni container, Autopilot assegna valori predefiniti dei container vengono eseguiti correttamente.
Quando esegui il deployment di un carico di lavoro in un cluster Autopilot, convalida la configurazione del carico di lavoro rispetto al valore minimo e massimo consentiti per i valori selezionati compute class o configurazione hardware (ad esempio GPU). Se le tue richieste inferiore al minimo, Autopilot modifica automaticamente il carico di lavoro per portare le tue richieste nell'intervallo consentito. Se le tue richieste sono superiori al limite massimo, Autopilot rifiuta il carico di lavoro e visualizza un messaggio di errore.
Nell'elenco seguente sono riepilogate le categorie delle richieste di risorse:
- Richieste di risorse predefinite: Autopilot le aggiunge se non specificare le tue richieste per i carichi di lavoro
- Richieste di risorse minime e massime: Autopilot convalida le richieste specificate per garantire che entro questi limiti. Se le tue richieste non rientrano nei limiti, Autopilot modifica le richieste dei carichi di lavoro.
- Richieste di separazione dei carichi di lavoro e di durata estesa: Autopilot ha valori predefiniti e valori minimi differenti per i carichi di lavoro separati tra loro o per i pod che ricevono la protezione estesa Eliminazione avviata da GKE.
- Richieste di risorse per DaemonSet: Autopilot ha valori predefiniti diversi, i valori minimo e massimo dei container in DaemonSet.
Come richiedere risorse
In Autopilot, richiedi risorse nella specifica del pod. La le risorse minime e massime supportate che puoi richiedere di modificare in base del nodo su cui vengono eseguiti i pod. Per scoprire come richiedere configurazioni hardware specifiche, consulta le seguenti pagine:
- Scegli le classi di calcolo 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 carichi di lavoro più piccoli.
Inoltre, Autopilot applica le seguenti richieste di risorse predefinite a prescindere dalla classe di computing o dalla configurazione hardware selezionata:
Container in DaemonSet
- CPU: 50 mCPU
- Memoria: 100 MiB
- Archiviazione temporanea: 100 MiB
Tutti gli altri container
- Spazio di archiviazione temporaneo: 1 GiB
Per saperne di più sui limiti dei cluster Autopilot, Quote e limiti.
Richieste predefinite per le classi di computing
Autopilot applica i seguenti valori predefiniti alle risorse che non definito nella specifica del pod per i pod in esecuzione classi di computing. Se imposti solo una delle richieste e lasci vuota l'altra, GKE utilizza il rapporto CPU:memoria definito Richieste minime e massime per impostare la richiesta mancante su un valore conforme al rapporto.
Classe di calcolo | Risorsa | Richiesta predefinita |
---|---|---|
Per uso generico (predefinito) | CPU | 0,5 vCPU |
Memoria | 2 GiB | |
Acceleratore | Consulta la sezione Risorse predefinite per gli acceleratori. | |
Bilanciato | CPU | 0,5 vCPU |
Memoria | 2 GiB | |
Prestazioni | CPU |
|
Memoria |
|
|
Archiviazione temporanea |
|
|
Scale out | CPU | 0,5 vCPU |
Memoria | 2 GiB |
Richieste predefinite per gli acceleratori
La tabella seguente descrive i valori predefiniti che GKE
assegna ai pod che non specificano valori nel campo requests
del pod
la specifica del container. Questa tabella si applica ai pod che utilizzano l'istanza di computing Accelerator
, che è il metodo consigliato per eseguire gli acceleratori in Autopilot
cluster.
Acceleratore | Risorsa | Richiesta predefinita totale |
---|---|---|
GPU NVIDIA H100 (80 GB)nvidia-h100-80gb |
CPU |
|
Memoria |
|
|
Archiviazione temporanea |
|
|
GPU NVIDIA A100 (40 GB)nvidia-tesla-a100 |
CPU |
|
Memoria |
|
|
GPU NVIDIA A100 (80 GB)nvidia-a100-80gb |
CPU |
|
Memoria |
|
|
Archiviazione temporanea |
|
|
GPU NVIDIA L4nvidia-l4 |
CPU |
|
Memoria |
|
|
GPU NVIDIA T4nvidia-tesla-t4 |
CPU |
|
Memoria |
|
|
TPU v5etpu-v5-lite-device (host singolo) |
CPU | Tutte le topologie: 1 mCPU |
Memoria | Tutte le topologie: 1 MiB | |
TPU v5etpu-v5-lite-podslice (multi-host) |
CPU | Tutte le topologie: 1 mCPU |
Memoria | Tutte le topologie: 1 MiB | |
TPU v5ptpu-v5p-slice |
CPU | Tutte le topologie: 1 mCPU |
Memoria | Tutte le topologie: 1 MiB | |
TPU v4tpu-v4-podslice |
CPU | Tutte le topologie: 1 mCPU |
Memoria | Tutte le topologie: 1 MiB |
GPU supportate senza classe di calcolo Accelerator
Se non utilizzi la classe di calcolo Accelerator, vengono utilizzate solo le seguenti GPU supportati. Le richieste di risorse predefinite per queste GPU sono le stesse di quelle la classe di computing Accelerator:
- NVIDIA A100 (40GB)
- NVIDIA A100 (80GB)
- NVIDIA L4
- NVIDIA Tesla T4
Richieste di risorse minime e massime
Le risorse totali richieste dalla configurazione del deployment devono essere comprese all'interno i valori minimo e massimo supportati consentiti da Autopilot. La si applicano le seguenti condizioni:
Richieste di archiviazione temporanea:
L'archiviazione temporanea utilizza il disco di avvio della VM, a meno che i nodi non dispongano di SSD locali in allegato.
Hardware per il calcolo che include SSD locali come GPU A100 (80 GB), Le GPU H100 (80 GB) o la serie di macchine Z3 supportano richiesta uguale alle dimensioni dell'SSD locale meno qualsiasi sistema overhead. Per informazioni sull'overhead del sistema, vedi Archiviazione temporanea supportata da SSD locali.
In GKE versione 1.29.3-gke.1038000 e successive, pod delle classi Performance I pod di acceleratore hardware supportano una richiesta massima di archiviazione temporanea 56 Ti, a meno che l'hardware non includa SSD locali.
In tutti gli altri pod Autopilot, indipendentemente della versione precedente, la richiesta di spazio di archiviazione temporaneo deve essere compresa tra 10 MiB e 10 GiB se non diversamente specificato.
Per volumi più grandi, utilizza volumi temporanei generici, che forniscono funzionalità e prestazioni equivalenti alle app ma con una flessibilità notevolmente maggiore in quanto possono essere utilizzati con qualsiasi opzione di archiviazione GKE. Ad esempio, la dimensione massima di un il volume temporaneo generico che utilizza
pd-balanced
è di 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 cluster supporta il bursting, vedi Disponibilità a più livelli in GKE.
Se il tuo cluster supporta il bursting, Autopilot non applica 0,25 vCPU per le richieste di CPU del pod. Se il cluster non supporta bursting, Autopilot arrotonda le richieste di CPU al bursting più vicino 0,25 vCPU. Per verificare se il cluster supporta il bursting, vedi Disponibilità a più livelli in GKE.
Il rapporto CPU:memoria deve rientrare nell'intervallo consentito per il valore selezionato di calcolo o di configurazione hardware. Se il rapporto CPU/memoria è al di fuori dell'intervallo consentito, Autopilot aumenta automaticamente una risorsa più piccola. Ad esempio, se richiedi 1 vCPU e 16 GiB di memoria (proporzioni 1:16) per i pod in esecuzione nella classe
Scale-Out
, Autopilot aumenta la richiesta di CPU a 4 vCPU, il che cambia il rapporto in 1:4.
Valori minimi e massimi per le classi di calcolo
La tabella seguente descrive il rapporto CPU-memoria minimo, massimo e consentito per ogni classe di computing supportata da Autopilot:
Classe di calcolo | Rapporto CPU:memoria (vCPU:GiB) | Risorsa | Minimo | Massimo |
---|---|---|---|---|
Per uso generico (predefinito) | Tra 1:1 e 1:6,5 | CPU | Il valore dipende dal fatto che il cluster supporta il bursting, nel seguente modo:
Per verificare se il cluster supporta il bursting, vedi Disponibilità a più livelli in GKE. |
30 vCPU |
Memoria | Il valore dipende dal fatto che il cluster supporta il bursting, nel seguente modo:
Per verificare se il cluster supporta il bursting, vedi Disponibilità a più livelli in GKE. |
110 GiB | ||
Acceleratore | Vedi Minimi e massimi per gli acceleratori | |||
Bilanciato | Tra 1:1 e 1:8 | CPU | 0,25 vCPU | 222 vCPU Se la piattaforma CPU minima selezionato:
|
Memoria | 0,5 GiB | 851 GiB Se la piattaforma CPU minima selezionato:
|
||
Prestazioni | N/D | CPU | 0,001 vCPU |
|
Memoria | 1 MiB |
|
||
Archiviazione temporanea | 10 MiB |
Nella versione 1.29.3-gke.1038000 e successive, puoi specificare un numero massimo richiesta di spazio di archiviazione temporaneo di 56 Ti, a meno che l'hardware non includa SSD. |
||
Scale out | 1:4 | CPU | 0,25 vCPU |
|
Memoria | 1 GiB |
|
Per scoprire come richiedere classi di calcolo nei pod Autopilot, consulta a Scegli le classi di calcolo per i pod Autopilot.
Minimi e massimi per gli acceleratori
Le seguenti sezioni descrivono il rapporto CPU-memoria minimo, massimo e consentito per i pod che utilizzano acceleratori hardware come GPU e TPU.
Se non specificato, lo spazio di archiviazione temporaneo massimo supportato è di 122 GiB nelle versioni 1.28.6-gke.1369000 o versioni successive e 1.29.1-gke.1575000 o versioni successive. Per i precedenti lo spazio di archiviazione temporaneo massimo supportato è di 10 GiB.
Valori minimi e massimi per la classe di calcolo Accelerator
La tabella seguente mostra le richieste di risorse minime e massime per i pod che usano la classe di computing Accelerator, che è il metodo consigliato per eseguire con i cluster GKE Autopilot. All'acceleratore di computing, GKE non applica il rapporto CPU-memoria.
Tipo di acceleratore | Risorsa | Minimo | Massimo |
---|---|---|---|
NVIDIA H100 (80GB)nvidia-h100-80gb |
CPU |
|
|
Memoria |
|
|
|
Archiviazione temporanea |
|
|
|
NVIDIA A100 (40GB)nvidia-tesla-a100 |
CPU | 0,001 vCPU |
La somma delle richieste di CPU di tutti i DaemonSet in esecuzione su una GPU A100 non deve superare le 2 vCPU. |
Memoria | 1 MiB |
La somma delle richieste di memoria di tutti i DaemonSet in esecuzione su una GPU A100 non deve superare i 14 GiB. |
|
NVIDIA A100 (80GB)nvidia-a100-80gb |
CPU | 0,001 vCPU |
La somma delle richieste di CPU di tutti i DaemonSet in esecuzione su una GPU A100 (80 GB) non deve superare le 2 vCPU. |
Memoria | 1 MiB |
La somma delle richieste di memoria di tutti i DaemonSet in esecuzione su una GPU A100 (80 GB) non deve superare i 14 GiB. |
|
Archiviazione temporanea | 512 MiB |
|
|
NVIDIA L4nvidia-l4 |
CPU | 0,001 vCPU |
La somma delle richieste di CPU di tutti i DaemonSet in esecuzione su una GPU L4 non deve superare le 2 vCPU. |
Memoria | 1 MiB |
La somma delle richieste di memoria di tutti i DaemonSet in esecuzione su una GPU L4 non deve superare i 14 GiB. |
|
NVIDIA Tesla T4nvidia-tesla-t4 |
CPU | 0,001 vCPU |
|
Memoria | 1 MiB |
|
|
TPU v5etpu-v5-lite-device |
CPU | 0,001 vCPU |
|
Memoria | 1 MiB |
|
|
Archiviazione temporanea | 10 MiB | 56 TiB | |
TPU v5etpu-v5-lite-podslice |
CPU | 0,001 vCPU |
|
Memoria | 1 MiB |
|
|
Archiviazione temporanea | 10 MiB | 56 TiB | |
TPU v5ptpu-v5p-slice |
CPU | 0,001 vCPU | 280 vCPU |
Memoria | 1 MiB | 448 GiB | |
Archiviazione temporanea | 10 MiB | 56 TiB | |
TPU v4tpu-v4-podslice |
CPU | 0,001 vCPU | 240 vCPU |
Memoria | 1 MiB | 407 GiB | |
Archiviazione temporanea | 10 MiB | 56 TiB |
Per scoprire come richiedere GPU nei pod Autopilot, consulta Esegui il deployment dei carichi di lavoro GPU in Autopilot.
Valori minimi e massimi per le GPU senza classe di computing
La tabella seguente mostra le richieste di risorse minime e massime per i pod che non utilizzano la classe di computing Accelerator:
Tipo di GPU | Rapporto CPU:memoria (vCPU:GiB) | Risorsa | Minimo | Massimo |
---|---|---|---|---|
NVIDIA A100 (40GB)nvidia-tesla-a100 |
Non applicato | CPU |
|
La somma delle richieste di CPU di tutti i DaemonSet in esecuzione su una GPU A100 non deve superare le 2 vCPU. |
Memoria |
|
La somma delle richieste di memoria di tutti i DaemonSet in esecuzione su una GPU A100 non deve superare i 14 GiB. |
||
NVIDIA A100 (80GB)nvidia-a100-80gb |
Non applicato | CPU |
|
La somma delle richieste di CPU di tutti i DaemonSet in esecuzione su una GPU A100 (80 GB) non deve superare le 2 vCPU. |
Memoria |
|
La somma delle richieste di memoria di tutti i DaemonSet in esecuzione su una 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 in esecuzione su una GPU L4 non deve superare le 2 vCPU. |
Memoria |
|
La somma delle richieste di memoria di tutti i DaemonSet in esecuzione su una GPU L4 non deve superare i 14 GiB. |
||
NVIDIA Tesla T4nvidia-tesla-t4 |
Tra 1:1 e 1:6,25 | CPU | 0,5 vCPU |
|
Memoria | 0,5 GiB |
|
Per scoprire come richiedere GPU nei pod Autopilot, consulta Esegui il deployment dei carichi di lavoro GPU in Autopilot.
Richieste di risorse per la separazione dei carichi di lavoro e la durata estesa
Autopilot consente di manipolare la pianificazione e l'eliminazione di Kubernetes il comportamento degli utenti con metodi quali:
- Utilizzare incompatibilità e tolleranze e selettori di nodi per assicurarti che determinati pod vengano posizionati solo su nodi specifici. Per maggiori dettagli, consulta Configurare la separazione dei carichi di lavoro in GKE.
- Utilizza le funzionalità di Anti-affinità dei pod per impedire la co-location dei pod sullo stesso nodo. I valori predefiniti e minimi richieste di risorse per carichi di lavoro che usano questi metodi per controllare la pianificazione sono più alti rispetto a quelli dei carichi di lavoro che non lo fanno.
- Utilizza un'annotazione per proteggere i pod dall'eliminazione causata dal nodo di upgrade automatici e scale down per un massimo di sette giorni. Per maggiori dettagli, vedi Estendi il tempo di esecuzione dei pod Autopilot.
Se le richieste specificate sono inferiori ai valori minimi, il comportamento Autopilot cambia in base al metodo utilizzato, come segue:
- Incompatibilità, tolleranze, selettori e pod di durata estesa: Autopilot modifica la tua per aumentare le richieste durante la pianificazione dei pod.
- Anti-affinità pod: Autopilot rifiuta il pod e mostra un .
La tabella seguente descrive le richieste predefinite e il numero minimo di risorse richieste che puoi specificare. Se una configurazione o una classe di computing non è in questo Autopilot non applica valori minimi o predefiniti speciali.
Classe di calcolo | Risorsa | Predefinito | Minimo |
---|---|---|---|
Per uso generico | CPU | 0,5 vCPU | 0,5 vCPU |
Memoria | 2 GiB | 0,5 GiB | |
Bilanciato | CPU | 2 vCPU | 1 vCPU |
Memoria | 8 GiB | 4 GiB | |
Scale out | CPU | 0,5 vCPU | 0,5 vCPU |
Memoria | 2 GiB | 2 GiB |
Container inizializzazione
I container init vengono eseguiti in serie e devono essere completati prima dell'applicazione dei container. Se non specifichi richieste di risorse per Container di init Autopilot, GKE alloca il totale a ogni container di inizializzazione disponibili per il pod. Questo comportamento è in modo diverso rispetto a GKE Standard, dove ogni il container può utilizzare qualsiasi risorsa non allocata disponibile nel nodo su cui Il pod è pianificato.
A differenza dei container di applicazioni, GKE consiglia non è necessario specificare richieste di risorse per i container init Autopilot, e ogni container riceve tutte le risorse disponibili per il pod. Se richiedi meno rispetto a quelle predefinite, il container init viene vincolato. Se richiedi più risorse rispetto a quelle predefinite di Autopilot, potresti aumentare per tutta la durata del pod.
Impostazione dei limiti delle risorse in Autopilot
Kubernetes consente di impostare sia requests
sia limits
per le risorse
la specifica del pod. Il comportamento dei pod cambia a seconda che le tue
limits
è diverso da requests
, come descritto di seguito
tabella:
Valori impostati | Comportamento 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 supporta il bursting, nel seguente modo:
Per verificare se il cluster supporta il bursting, vedi Disponibilità a più livelli in GKE. |
Valore requests non impostato, limits impostato |
Autopilot imposta requests sul valore
di limits , che è il comportamento predefinito di Kubernetes.
Prima del: resources: limits: cpu: "400m" Dopo il: resources: requests: cpu: "400m" limits: cpu: "400m" |
requests in meno rispetto a limits |
Il comportamento dipende dal fatto che il cluster supporta il bursting, nel seguente modo:
Per verificare se il cluster supporta il bursting, vedi Disponibilità a più livelli in GKE. |
requests maggiore di limits |
Autopilot imposta requests sul valore
di limits .
Prima del: resources: requests: cpu: "450m" limits: cpu: "400m" Dopo il: resources: requests: cpu: "400m" limits: cpu: "400m" |
requests non impostata, limits non impostata |
Autopilot imposta Il comportamento per
Per verificare se il cluster supporta il bursting, vedi Disponibilità a più livelli in GKE. |
Nella maggior parte delle situazioni, imposta richieste di risorse adeguate e limiti uguali per carichi di lavoro con scale out impegnativi.
Per i carichi di lavoro che hanno temporaneamente bisogno di più risorse se è stabile, ad esempio durante l'avvio o durante i periodi di traffico più elevato, limiti superiori alle tue richieste per consentire il burst dei pod. Per maggiori dettagli, vedi Configura il bursting dei pod in GKE.
Gestione automatica delle risorse in Autopilot
Se le richieste di risorse specificate per i carichi di lavoro sono al di fuori del consentiti oppure, se non richiedi risorse per alcuni container, Autopilot modifica la configurazione del carico di lavoro per rispettare le consentiti. Autopilot calcola i rapporti delle risorse i requisiti di scale up delle risorse dopo l'applicazione di valori predefiniti ai container senza una richiesta specificata.
- Richieste mancanti: se non richiedi risorse in alcuni contenitori, Autopilot applica le richieste predefinite per la classe di computing configurazione hardware.
- Rapporto CPU:memoria:Autopilot fa lo scale up della risorsa più piccola verso il rapporto deve rientrare nell'intervallo consentito.
- Archiviazione temporanea: Autopilot modifica lo spazio di archiviazione temporaneo. per soddisfare la quantità minima richiesta da ciascun container. La il valore cumulativo delle richieste di archiviazione in tutti i container non può essere superiore rispetto al valore massimo consentito. Prima di 1.28.6-gke.1317000, Autopilot fa lo scale down dell'archiviazione temporanea richiesta se il valore supera il massimo. Nella versione 1.28.6-gke.1317000 e successive, Autopilot rifiuta il carico di lavoro.
- Richieste al di sotto del minimo: se richiedi meno risorse rispetto al minimo consentito per la configurazione hardware selezionata, Autopilot modifica automaticamente il pod per richiedere almeno il numero minimo di risorse valore.
Per impostazione predefinita, quando Autopilot scala automaticamente una risorsa per soddisfare
un valore minimo o predefinito della risorsa, GKE alloca
al primo container nel manifest del pod. In GKE
versione 1.27.2-gke.2200 e successive, puoi dire a GKE di allocare
le risorse aggiuntive in 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
containerizzato.
Esempi di modifica delle risorse
Lo scenario di esempio seguente mostra in che modo Autopilot modifica della configurazione dei carichi di lavoro per soddisfare i requisiti dei pod in esecuzione containerizzati.
Container singolo con < 0,05 vCPU
Numero contenitore | Richiesta originale | Richiesta modificata |
---|---|---|
1 |
CPU: 30 mCPU Memoria: 0,5 GiB Archiviazione temporanea: 10 MiB |
CPU: 50 mCPU Memoria: 0,5 GiB Archiviazione temporanea: 10 MiB |
Più container con CPU totale < 0,05 vCPU
Numero contenitore | Richieste originali | Richieste modificate |
---|---|---|
1 | CPU: 10 mCPU Memoria: 0,5 GiB Archiviazione temporanea: 10 MiB |
CPU: 30 mCPU Memoria: 0,5 GiB Archiviazione temporanea: 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 Archiviazione temporanea: 10 MiB |
CPU: 10 mCPU Memoria: 0,5 GiB Archiviazione temporanea: 10 MiB |
Risorse pod totali | 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 (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 contenitore | Richiesta originale | Richiesta modificata |
---|---|---|
1 | CPU: 4 vCPU Memoria: 1 GiB Archiviazione temporanea: 10 MiB |
CPU: 4 vCPU Memoria: 4 GiB Archiviazione temporanea: 10 MiB |
Risorse pod totali | CPU: 4 vCPU Memoria: 4 GiB Archiviazione temporanea: 10 MiB |
Passaggi successivi
- Scopri come selezionare le classi di computing in Autopilot carichi di lavoro standard.
- Scopri di più sulle classi di calcolo Autopilot supportate.
- Scopri come selezionare GPU nei pod Autopilot.