Questa pagina descrive le richieste di risorse massime, minime e predefinite che puoi specificare per i tuoi carichi di lavoro Autopilot in Google Kubernetes Engine (GKE) e in che modo Autopilot modifica automaticamente tali 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 computing 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 calcolo o la configurazione hardware selezionata (ad esempio le GPU). Se il numero di richieste è inferiore al minimo, Autopilot modifica automaticamente la configurazione dei carichi di lavoro per portare le richieste entro l'intervallo consentito. Se le richieste sono superiori al massimo, Autopilot rifiuta il carico di lavoro e mostra 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 minime e massime di risorse: Autopilot convalida le richieste specificate per garantire che rientrino entro questi limiti. Se le tue richieste superano i limiti, Autopilot modifica le richieste dei carichi 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 l'uno dall'altro o per i pod che ricevono una protezione estesa dall'eliminazione avviata da GKE.
- Richieste di risorse per i DaemonSet: la modalità Autopilot ha valori predefiniti, minimi e massimi diversi per i container in DaemonSet.
Come richiedere risorse
In Autopilot, richiedi risorse nella specifica del pod. Il numero minimo e massimo di risorse supportate che puoi richiedere 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 carichi di lavoro delle 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. Questi valori predefiniti sono adatti per 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
- Spazio di archiviazione temporaneo: 100 MiB
Tutti gli altri contenitori
- Spazio di archiviazione temporaneo: 1 GiB
Per ulteriori informazioni sui limiti dei cluster Autopilot, consulta Quote e limiti.
Richieste predefinite per classi di computing
Autopilot applica i seguenti valori predefiniti alle risorse che non sono definite nella specifica del pod per i pod eseguiti su classi di computing. Se imposti una sola 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 computing | Risorsa | Richiesta predefinita |
|---|---|---|
| Per uso generico | CPU | 0,5 vCPU |
| Memoria | 2 GiB | |
| 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 altre configurazioni hardware
Autopilot applica i seguenti valori predefiniti alle risorse non definite nella specifica del pod per i pod eseguiti su nodi con hardware specializzato, come le GPU:
| Hardware | Risorsa | Richiesta predefinita totale |
|---|---|---|
GPU H100 (80 GB)nvidia-h100-80gb |
CPU |
|
| Memoria |
|
|
| Archiviazione temporanea |
|
|
GPU A100 (40 GB)nvidia-tesla-a100 |
CPU |
|
| Memoria |
|
|
GPU A100 (80 GB)nvidia-a100-80gb |
CPU |
|
| Memoria |
|
|
| Archiviazione temporanea |
|
|
GPU L4nvidia-l4 |
CPU |
|
| Memoria |
|
|
GPU T4nvidia-tesla-t4 |
CPU | 0,5 vCPU |
| Memoria | 2 GiB |
Numero minimo e massimo di richieste di risorse
Le risorse totali richieste dalla configurazione del deployment devono rientrare nei valori minimo e massimo supportati consentiti da Autopilot. Si applicano le seguenti condizioni:
- Se non diversamente specificato, la richiesta di archiviazione temporanea deve essere compresa tra 10 MiB e 10 GiB per tutte
le classi di calcolo e le configurazioni hardware. Per i volumi più grandi, consigliamo di utilizzare volumi temporanei generici che forniscono funzionalità e prestazioni equivalenti all'archiviazione temporanea, ma con una flessibilità notevolmente maggiore, poiché possono essere utilizzati con qualsiasi opzione di archiviazione GKE. Ad esempio, la dimensione massima per un volume temporaneo generico che utilizza
pd-balancedè 64 TiB. Per i pod DaemonSet, il numero minimo di richieste di risorse è il seguente:
- 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 Bursting della disponibilità in GKE.
Il rapporto CPU:memoria deve essere compreso 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 nella classe
Scale-Out, Autopilot aumenta la richiesta di CPU a 4 vCPU, modificando 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 | Tra 1:1 e 1:6,5 | CPU | Il valore dipende dal supporto del bursting nel cluster, come segue:
Per verificare se il tuo cluster supporta il bursting, consulta Bursting della disponibilità in GKE. |
30 vCPU |
| Memoria | Il valore dipende dal supporto del bursting nel cluster, come segue:
Per verificare se il tuo cluster supporta il bursting, consulta Bursting della disponibilità in GKE. |
110 GiB | ||
| Bilanciato | Tra 1:1 e 1:8 | CPU | 0,25 vCPU | 222 vCPU Se viene selezionata la piattaforma CPU minima:
|
| Memoria | 0,5 GiB | 851 GiB Se viene selezionata la piattaforma CPU minima:
|
||
| Prestazioni | N/D | 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 le classi di computing nei pod Autopilot, consulta Scegliere le classi di computing per i pod Autopilot.
Valori minimi e massimi per altre configurazioni hardware
La seguente tabella descrive il rapporto CPU/memoria minimo, massimo e consentito per i pod in esecuzione su nodi con hardware specifico come le GPU. 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 è 10 GiB.
| Hardware | Rapporto CPU:memoria (vCPU:GiB) | Risorsa | Minimo | Massimo |
|---|---|---|---|---|
GPU H100 (80 GB)nvidia-h100-80gb |
Non applicato | CPU |
|
|
| Memoria |
|
|
||
| Archiviazione temporanea |
|
|
||
GPU A100 (40 GB)nvidia-tesla-a100 |
Non applicato | CPU |
|
La somma delle richieste di CPU di tutti i DaemonSet eseguiti su un nodo GPU A100 non deve superare le 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. |
||
GPU A100 (80 GB)nvidia-a100-80gb |
Non applicato | CPU |
|
La somma delle richieste di CPU di tutti i DaemonSet eseguiti su un nodo GPU A100 (80 GB) non deve superare le 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 |
|
|
||
GPU 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. |
||
GPU 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 e la durata estesa dei carichi di lavoro
Autopilot consente di manipolare la pianificazione e il comportamento dell'eliminazione di Kubernetes utilizzando metodi come i seguenti:
- 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 che i pod si trovino 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 superiori rispetto a quelle per i carichi di lavoro che non usano questi metodi.
- Utilizza un'annotazione per proteggere i pod dall'eliminazione causata dagli upgrade automatici dei nodi e dagli eventi di scale down fino a sette giorni. Per maggiori dettagli, consulta Estendi il tempo 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:
- Incompatibilità, tolleranze, selettori e pod di durata estesa: la modalità Autopilot modifica i pod per aumentare le richieste durante la pianificazione dei pod.
- Anti-affinità del pod: la modalità Autopilot rifiuta il pod e mostra un messaggio di errore.
La seguente tabella descrive le richieste predefinite e il numero minimo di richieste di risorse che puoi specificare. Se una configurazione o una classe di computing non è 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 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 di inizializzazione vengono eseguiti in serie e devono essere completati prima dell'avvio dei container dell'applicazione. Se non specifichi le richieste di risorse per i container init Autopilot, GKE alloca le risorse totali disponibili per il pod a ciascun container di inizializzazione. Questo comportamento è diverso rispetto a 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 di inizializzazione Autopilot, in modo che ciascun container riceva tutte le risorse disponibili per il pod. Se richiedi meno risorse rispetto ai valori predefiniti, limiti il container init. Se richiedi più risorse rispetto ai valori predefiniti di Autopilot, potresti aumentare la tua fattura per la durata del pod.
Impostazione dei limiti di 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 siano diversi da quelli di requests, come descritto nella seguente 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 supporti il bursting, come segue:
Per verificare se il tuo cluster supporta il bursting, consulta Bursting della disponibilità in GKE. |
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 tuo cluster supporta il bursting, consulta Bursting della disponibilità in GKE. |
requests maggiore di limits |
Autopilot imposta requests sul valore
limits.
Prima del:
resources:
requests:
cpu: "450m"
limits:
cpu: "400m"
Dopo il:
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 Bursting della disponibilità in GKE. |
Nella maggior parte dei casi, imposta richieste di risorse adeguate e limiti uguali per i carichi di lavoro.
Per i carichi di lavoro che richiedono temporaneamente più risorse rispetto allo stato stazionario, ad esempio durante l'avvio o i periodi di traffico più elevato, imposta limiti superiori alle richieste per consentire il bursting 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 tuoi carichi di lavoro non rientrano negli intervalli consentiti o se non richiedi risorse per alcuni container, Autopilot modifica la configurazione dei carichi 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 entro l'intervallo consentito.
- Archiviazione temporanea: Autopilot modifica le richieste di archiviazione temporanee 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 esegue lo scale down della richiesta se il valore supera il valore massimo.
- Richieste inferiori al minimo: se richiedi un numero di risorse inferiore 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 scala automaticamente una risorsa fino a raggiungere un valore minimo o predefinito, GKE alloca la capacità extra 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 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 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 contenitore | 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 pod totali | CPU: 50 mCPU Memoria: 1,5 GiB Spazio di archiviazione temporaneo: 30 MiB |
Più container con più di 0,25 vCPU totali
Per più container con risorse totali >= 0,25 vCPU, la CPU viene arrotondata a multipli di 0,25 vCPU e la CPU in più viene aggiunta al primo container. In questo esempio, la CPU cumulativa originale è di 0,32 vCPU e viene modificata in un totale di 0,5 vCPU.
| Numero contenitore | Richieste originali | Richieste modificate |
|---|---|---|
| 1 | CPU: 0,17 vCPU Memoria: 0,5 GiB Spazio di archiviazione temporaneo: 10 MiB |
CPU: 0,35 vCPU Memoria: 0,5 GiB Spazio di archiviazione temporaneo: 10 MiB |
| 2 | CPU: 0,08 vCPU Memoria: 0,5 GiB Spazio di archiviazione temporaneo: 10 MiB |
CPU: 0,08 vCPU Memoria: 0,5 GiB Spazio di archiviazione temporaneo: 10 MiB |
| 3 | CPU: 0,07 vCPU Memoria: 0,5 GiB Spazio di archiviazione temporaneo: 10 MiB |
CPU: 0,07 vCPU Memoria: 0,5 GiB Spazio di archiviazione temporaneo: 10 MiB |
| 4 | Container di inizializzazione, risorse non definite | Riceverà risorse pod |
| Risorse pod totali | CPU: 0,5 vCPU Memoria: 1,5 GiB Spazio di archiviazione temporaneo: 30 MiB |
Singolo container con memoria troppo insufficiente 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 aumenta.
| 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 computing di Autopilot supportate.
- Scopri come selezionare le GPU nei tuoi pod Autopilot.