Questa pagina descrive le richieste di risorse massime, minime e predefinite che puoi specificare per i tuoi carichi di lavoro Autopilot di Google Kubernetes Engine (GKE) e in che modo Autopilot modifica automaticamente queste richieste per mantenere la stabilità dei carichi di lavoro.
Panoramica delle richieste di risorse in Autopilot
Autopilot utilizza le richieste di risorse specificate nella configurazione dei carichi di lavoro per configurare i nodi che eseguono i carichi di lavoro. Autopilot applica le richieste di risorse minime e massime in base alla classe di calcolo o alla configurazione hardware utilizzata dai carichi di lavoro. Se non specifichi le richieste per alcuni container, Autopilot assegna valori predefiniti per consentire l'esecuzione corretta di questi container.
Quando esegui il deployment di un carico di lavoro in un cluster Autopilot, GKE convalida la configurazione del carico di lavoro in base ai valori minimo e massimo 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 dei carichi di lavoro per riportarle all'interno dell'intervallo consentito. Se le richieste superano il limite massimo, Autopilot rifiuta il carico di lavoro e visualizza un messaggio di errore.
Il seguente elenco riassume le categorie di richieste di risorse:
- Richieste di risorse predefinite: Autopilot le aggiunge se non specifichi le tue richieste per i carichi di lavoro
- Richieste di risorse minime e massime: Autopilot convalida le richieste specificate per garantire che rientrino in questi limiti. Se le tue richieste non rientrano nei limiti, Autopilot modifica le richieste del carico di lavoro.
- Richieste di separazione del carico di lavoro e durata estesa: Autopilot ha valori predefiniti diversi e valori minimi diversi per i carichi di lavoro separati tra loro o per i pod che ricevono una protezione estesa dall'eliminazione avviata da GKE.
- Richieste di risorse per DaemonSet: Autopilot ha valori predefiniti, minimi e massimi per i container in DaemonSet.
Come richiedere risorse
In Autopilot, richiedi 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 informazioni su 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 indipendentemente 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, 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 in esecuzione su classi di computing. Se imposti solo una delle richieste e lasci vuota l'altra, 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 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 seguente tabella descrive i valori predefiniti che GKE assegna ai pod che non specificano valori nel campo requests
della specifica del pod. Questa tabella si applica ai pod che utilizzano la classe di computing Accelerator
, che è il metodo consigliato per eseguire gli acceleratori nei cluster Autopilot.
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, sono supportate solo le seguenti GPU. Le richieste di risorse predefinite per queste GPU sono le stesse della classe di calcolo 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 rientrare nei valori minimo e massimo supportati consentiti da Autopilot. Si applicano le seguenti condizioni:
- La richiesta di archiviazione temporanea deve essere compresa tra 10 MiB e 10 GiB per tutte le classi di computing e le configurazioni hardware, se non diversamente specificato. Per
volumi più grandi, ti consigliamo di utilizzare
volumi temporanei generici
che forniscono funzionalità e prestazioni equivalenti all'archiviazione temporanea,
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 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 spazio di archiviazione temporaneo 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, consulta Disponibilità a raffica in GKE.
Se il cluster supporta il bursting, Autopilot non applica incrementi di 0,25 vCPU per le richieste di CPU del pod. Se il cluster non supporta il bursting, Autopilot arrotonda le richieste di CPU a 0,25 vCPU più vicine. Per verificare se il cluster supporta il bursting, consulta Disponibilità a raffica in GKE.
Il rapporto CPU:memoria deve rientrare nell'intervallo consentito per la configurazione hardware o la classe di computing 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 (proporzioni 1:16) per i pod in esecuzione sulla 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 calcolo 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 dalla capacità del cluster di supportare il bursting, come segue:
Per verificare se il cluster supporta il bursting, consulta Disponibilità a raffica in GKE. |
30 vCPU |
Memoria | Il valore dipende dalla capacità del cluster di supportare il bursting, come segue:
Per verificare se il cluster supporta il bursting, consulta Disponibilità a raffica 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 è selezionata la piattaforma CPU minima:
|
Memoria | 0,5 GiB | 851 GiB Se è selezionata la piattaforma CPU minima:
|
||
Prestazioni | N/A | CPU | 0,001 vCPU |
|
Memoria | 1 MiB |
|
||
Archiviazione temporanea | 10 MiB |
|
||
Scale out | 1:4 | CPU | 0,25 vCPU |
|
Memoria | 1 GiB |
|
Per scoprire come richiedere classi di calcolo nei pod Autopilot, consulta Scegliere 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 successive e 1.29.1-gke.1575000 o successive. Per le versioni 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 utilizzano la classe di calcolo Accelerator, che è il metodo consigliato per eseguire gli acceleratori con i cluster GKE Autopilot. Nella classe di computing Accelerator, GKE non applica il rapporto di richiesta 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 un nodo GPU A100 non deve superare le 2 vCPU. |
Memoria | 1 MiB |
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 | 0,001 vCPU |
La somma delle richieste di CPU di tutti i DaemonSet in esecuzione su un nodo 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 un nodo 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 un nodo GPU L4 non deve superare le 2 vCPU. |
Memoria | 1 MiB |
La somma delle richieste di memoria di tutti i DaemonSet in esecuzione su un nodo 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 Eseguire 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 calcolo 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 un nodo GPU A100 non deve superare le 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 |
Non applicato | CPU |
|
La somma delle richieste di CPU di tutti i DaemonSet in esecuzione su un nodo GPU A100 (80 GB) non deve superare le 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 in esecuzione su un nodo GPU L4 non deve superare le 2 vCPU. |
Memoria |
|
La somma delle richieste di memoria di tutti i DaemonSet in esecuzione su un nodo 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 Eseguire 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 il comportamento della pianificazione e dell'eliminazione di Kubernetes
- Usa 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 l'anti-affinità dei pod per impedire la co-location dei pod sullo stesso nodo. Le richieste di risorse predefinite e minime per i carichi di lavoro che utilizzano questi metodi per controllare il comportamento della pianificazione sono maggiori rispetto ai carichi di lavoro che non lo fanno.
- Utilizza un'annotazione per proteggere i pod dall'eliminazione causata da upgrade automatici ed eventi di scale down dei nodi per un massimo di sette giorni. Per maggiori dettagli, consulta Estendi il tempo di esecuzione dei pod Autopilot.
Se le richieste specificate sono inferiori al minimo, il comportamento di Autopilot cambia in base al metodo utilizzato, come segue:
- Incompatibilità, tolleranze, selettori e pod di durata estesa: Autopilot modifica i tuoi 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 minime di risorse 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 calcolo | Risorsa | Predefinita | 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'avvio dei container dell'applicazione. Se non specifichi richieste di risorse per i tuoi container init Autopilot, GKE alloca le risorse totali disponibili per il pod a ciascun container init. Questo comportamento è diverso da quello di GKE Standard, in cui ogni container init può utilizzare qualsiasi risorsa non allocata disponibile nel nodo su cui è pianificato il pod.
A differenza dei container di applicazioni, GKE consiglia di non specificare richieste di risorse per i container init Autopilot, in modo che ogni container riceva le risorse complete disponibili per il pod. Se richiedi meno risorse di quelle predefinite, vincoli il tuo container init. Se richiedi più risorse rispetto a quelle predefinite di Autopilot, potresti aumentare la fatturazione per la durata del 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 pod cambia a seconda che limits
sia diverso da requests
, come descritto nella tabella seguente:
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 supporti il bursting, come segue:
Per verificare se il cluster supporta il bursting, consulta Disponibilità a raffica 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 supporti il bursting, come segue:
Per verificare se il cluster supporta il bursting, consulta Disponibilità a raffica 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 di
Per verificare se il cluster supporta il bursting, consulta Disponibilità a raffica in GKE. |
Nella maggior parte delle situazioni, imposta richieste di risorse adeguate e limiti uguali per i tuoi carichi di lavoro.
Per i carichi di lavoro che hanno bisogno temporaneamente di più risorse rispetto allo stato stazionario, ad esempio durante l'avvio o in periodi di traffico più elevati, imposta i limiti su un valore superiore alle richieste per consentire il burst dei pod. Per maggiori dettagli, consulta Configurare il bursting dei pod in GKE.
Gestione automatica delle risorse in Autopilot
Se le richieste di risorse specificate per i 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 delle risorse e i requisiti di scale up delle risorse dopo aver applicato 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 fa lo scale up della risorsa più piccola per portare il rapporto all'interno dell'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. Autopilot fa lo scale down della richiesta se il valore supera il limite massimo.
- Richieste al di sotto del minimo: se richiedi meno risorse rispetto al minimo consentito per la configurazione hardware selezionata, Autopilot modifica automaticamente il pod in modo che richieda almeno il valore minimo delle risorse.
Per impostazione predefinita, quando Autopilot scala automaticamente una risorsa per raggiungere un valore minimo o predefinito, GKE alloca la capacità aggiuntiva al primo container nel manifest del pod. In GKE 1.27.2-gke.2200 e versioni 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 in che modo Autopilot modifica la configurazione del carico di lavoro per soddisfare i requisiti dei pod e dei container in esecuzione.
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 Spazio di archiviazione temporaneo: 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 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 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 Spazio di archiviazione temporaneo: 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 contenitore | 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 pod totali | CPU: 4 vCPU Memoria: 4 GiB Spazio di archiviazione temporaneo: 10 MiB |
Passaggi successivi
- Scopri come selezionare le classi di computing nei carichi di lavoro Autopilot.
- Scopri di più sulle classi di calcolo Autopilot supportate.
- Scopri come selezionare GPU nei pod Autopilot.