Informazioni su ComputeClass personalizzate

Puoi creare le tue ComputeClass per controllare le proprietà dei nodi che Google Kubernetes Engine (GKE) esegue il provisioning durante la scalabilità automatica del cluster. Questa pagina è destinata agli amministratori delle piattaforme che vogliono definire in modo dichiarativo i profili di scalabilità automatica per i nodi, in modo che workload specifici vengano eseguiti su hardware che soddisfi i loro requisiti. Per saperne di più sulle ComputeClass, consulta Informazioni sulle ComputeClass di GKE.

Panoramica di ComputeClasses

In GKE, una ComputeClass è un profilo costituito da un insieme di attributi dei nodi che GKE utilizza per eseguire il provisioning dei nodi che eseguono i tuoi carichi di lavoro durante gli eventi di scalabilità automatica. ComputeClasses può scegliere come target ottimizzazioni specifiche, ad esempio il provisioning di nodi ad alte prestazioni o la definizione della priorità delle configurazioni ottimizzate per i costi per ridurre i costi di esecuzione. Le classi di calcolo personalizzate ti consentono di definire profili che GKE utilizza per scalare automaticamente i nodi in modo da soddisfare da vicino i requisiti di carichi di lavoro specifici.

Le ComputeClass personalizzate sono disponibili per l'utilizzo in modalità GKE Autopilot e GKE Standard nella versione 1.30.3-gke.1451000 e successive e offrono un approccio dichiarativo alla definizione degli attributi dei nodi e delle priorità di scalabilità automatica. Le ComputeClass personalizzate sono disponibili per la configurazione e l'utilizzo in tutti i cluster GKE idonei per impostazione predefinita.

Vantaggi di ComputeClass personalizzate

Le ComputeClass personalizzate offrono i seguenti vantaggi:

  • Priorità di calcolo di riserva: definisci una gerarchia di configurazioni dei nodi in ogni ComputeClass da dare la priorità a GKE. Se la configurazione preferita non è disponibile, GKE sceglie automaticamente la configurazione successiva nella gerarchia. Questo modello di fallback garantisce che anche quando le risorse di computing non sono disponibili, i tuoi carichi di lavoro vengano eseguiti su hardware ottimizzato con ritardi di pianificazione minimi.
  • Controllo granulare della scalabilità automatica: definisci le configurazioni dei nodi più adatte a workload specifici. GKE dà la priorità a queste configurazioni durante la creazione di nodi durante lo scaling.
  • Configurazione dichiarativa dell'infrastruttura: adotta un approccio dichiarativo alla gestione dell'infrastruttura in modo che GKE crei automaticamente nodi che corrispondano ai requisiti specifici del tuo carico di lavoro.
  • Migrazione attiva: se le risorse di computing per una configurazione della macchina preferita diventano disponibili nella tua località, GKE esegue automaticamente la migrazione dei tuoi carichi di lavoro ai nuovi nodi che utilizzano la configurazione preferita.
  • Ottimizzazione dei costi: dai la priorità ai tipi di nodo convenienti, come le VM spot, per ridurre le spese del cluster.
  • ComputeClass personalizzate predefinite: imposta una ComputeClass personalizzata come predefinita per un intero cluster o per spazi dei nomi Kubernetes specifici, in modo che i carichi di lavoro vengano eseguiti su hardware ottimizzato anche se non richiedono una ComputeClass specifica.
  • Soglie di consolidamento dei nodi personalizzate: definisci soglie di utilizzo delle risorse personalizzate per i nodi. Se l'utilizzo delle risorse di un nodo specifico scende al di sotto della soglia, GKE tenta di consolidare i carichi di lavoro in un nodo simile e disponibile e ridimensiona il nodo sottoutilizzato.

Casi d'uso per ComputeClass personalizzate

Prendi in considerazione l'utilizzo di ComputeClass personalizzate in scenari come i seguenti:

  • Vuoi eseguire i tuoi carichi di lavoro AI/ML su configurazioni specifiche di GPU o TPU.
  • Vuoi impostare configurazioni hardware predefinite per i workload eseguiti da team specifici, eliminando il sovraccarico per gli operatori delle applicazioni.
  • Esegui carichi di lavoro che funzionano in modo ottimale su serie di macchine o configurazioni hardware Compute Engine specifiche.
  • Vuoi dichiarare configurazioni hardware che soddisfano requisiti aziendali specifici, come prestazioni elevate, costi ottimizzati o alta disponibilità.
  • Vuoi che GKE esegua il fallback gerarchico all'utilizzo di configurazioni hardware specifiche durante l'indisponibilità delle risorse di computing, in modo che i tuoi carichi di lavoro vengano sempre eseguiti su macchine adatte ai loro requisiti.
  • Vuoi decidere centralmente le configurazioni ottimali per la flotta della tua azienda, in modo che i costi siano più prevedibili e i workload vengano eseguiti in modo più affidabile.
  • Vuoi specificare centralmente quali delle tue prenotazioni di capacità di Compute Engine devono essere utilizzate da GKE per il provisioning di nuovi nodi per carichi di lavoro specifici.
  • Vuoi specificare una policy di posizionamento compatto da utilizzare con GKE Autopilot. Per maggiori dettagli, vedi posizionamento compatto.

Come funzionano le ComputeClass personalizzate

Le ComputeClass personalizzate sono risorse personalizzate di Kubernetes che eseguono il provisioning dell'infrastrutturaGoogle Cloud . Definisci un oggetto ComputeClass nel cluster, quindi richiedi ComputeClass nei carichi di lavoro o imposta questa classe di calcolo come predefinita per uno spazio dei nomi Kubernetes. Quando un carico di lavoro corrispondente richiede una nuova infrastruttura, GKE esegue il provisioning di nuovi nodi in linea con le priorità che hai impostato nella definizione di ComputeClass.

Gli attributi che imposti in ComputeClasses definiscono il modo in cui GKE configura i nuovi nodi per eseguire i carichi di lavoro. Quando modifichi una classe di calcolo esistente, tutti i nodi futuri che GKE crea per quella classe di calcolo utilizzano la configurazione modificata. GKE non modifica retroattivamente la configurazione dei nodi esistenti in modo che corrispondano alle tue modifiche.

Le ComputeClass personalizzate influenzano le decisioni di scalabilità automatica, ma non vengono prese in considerazione da kube-scheduler. Durante la pianificazione dei pod, lo scheduler potrebbe non dare la priorità ai nodi con priorità ComputeClass personalizzate più elevate, anche quando sono disponibili nodi esistenti con varie priorità.

Per assicurarti che le tue ComputeClass personalizzate siano ottimizzate per la tua flotta, tieni presente le seguenti linee guida:

  • Comprendi i requisiti di calcolo del tuo parco, inclusi eventuali requisiti hardware specifici dell'applicazione.
  • Decidi un tema che guidi la progettazione di ogni ComputeClass. Ad esempio, una ComputeClass ottimizzata per il rendimento potrebbe avere una strategia di fallback che utilizza solo tipi di macchina con CPU elevata.
  • Decidi la famiglia e la serie di macchine Compute Engine più adatte ai tuoi workload. Per i dettagli, vedi la guida alle risorse e al confronto per le famiglie di macchine.
  • Pianifica una strategia di fallback all'interno di ogni ComputeClass in modo che i workload vengano sempre eseguiti su nodi che utilizzano configurazioni di macchine simili. Ad esempio, se la serie di macchine N4 non è disponibile, puoi eseguire il failover sulle macchine C3.

Visualizza la definizione di risorsa personalizzata completa

Per visualizzare la definizione di risorsa personalizzata (CRD) più recente per la risorsa personalizzata ComputeClass, inclusi tutti i campi e le relative relazioni, consulta la documentazione di riferimento di ComputeClass.

Puoi anche visualizzare la CRD nel cluster eseguendo questo comando:

kubectl describe crd computeclasses.cloud.google.com

Pianificare una ComputeClass personalizzata

Per pianificare, eseguire il deployment e utilizzare in modo efficace una ComputeClass personalizzata nel cluster, segui questi passaggi:

  1. Scegli le priorità di calcolo di riserva: definisci una serie di regole che regolano le proprietà dei nodi che GKE crea per ComputeClass.
  2. Configura i pool di nodi GKE Standard e ComputeClass: per i cluster in modalità Standard, esegui i passaggi di configurazione richiesti per utilizzare ComputeClass con i pool di nodi.
  3. Definisci il comportamento di scalabilità quando non vengono applicate regole di priorità: facoltativamente, indica a GKE cosa fare se non è possibile eseguire il provisioning dei nodi che soddisfano le regole di priorità.
  4. Imposta i parametri di scalabilità automatica per il consolidamento dei nodi: indica a GKE quando consolidare i carichi di lavoro e rimuovere i nodi sottoutilizzati.
  5. Configura la migrazione attiva ai nodi con priorità più alta: facoltativamente, indica a GKE di spostare i carichi di lavoro sui nodi preferiti man mano che l'hardware diventa disponibile.
  6. Consuma prenotazioni Compute Engine: facoltativamente, indica a GKE di consumare le prenotazioni Compute Engine zonali esistenti quando crei nuovi nodi.

Scegli le priorità di calcolo di riserva

Il vantaggio principale dell'utilizzo di una ComputeClass personalizzata è il controllo della strategia di fallback quando i nodi preferiti non sono disponibili a causa di fattori come l'esaurimento delle risorse e le limitazioni della quota.

Crea una strategia di riserva definendo un elenco di regole di priorità nella tua ComputeClass personalizzata. Quando un cluster deve essere scalato, GKE assegna la priorità alla creazione di nodi che corrispondono alla regola con la priorità più alta. Se GKE non riesce a creare questi nodi, torna alla regola di priorità successiva, ripetendo questo processo finché GKE non esegue lo scale up del cluster o esaurisce tutte le regole. Se tutte le regole sono esaurite, GKE crea nodi in base al comportamento predefinito o specificato descritto in Definisci il comportamento di scalabilità quando non si applicano regole di priorità.

Serie di macchine Compute Engine diverse supportano tecnologie e funzionalità diverse. Le generazioni precedenti di una serie di macchine potrebbero non supportare gli stessi tipi di archiviazione delle generazioni più recenti. Se esegui carichi di lavoro stateful che si basano su dati permanenti, evita di utilizzare una ComputeClass che si estende su più generazioni di una serie di macchine. I carichi di lavoro potrebbero non essere in grado di accedere ai dati permanenti se GKE li posiziona su un tipo di macchina che non supporta quel tipo di archiviazione. Per maggiori dettagli, filtra la tabella di confronto delle serie di macchine per tipi di archiviazione specifici.

Regole di priorità

Definisci le regole di priorità nel campo spec.priorities della risorsa personalizzata ComputeClass. Ogni regola nel campo priorities descrive le proprietà dei nodi da eseguire il provisioning. GKE elabora il campo priorities in ordine, il che significa che il primo elemento del campo ha la priorità più alta per il provisioning dei nodi.

Esistono due tipi di regole di priorità:

  • Tipi di regole dichiarative: utilizza le caratteristiche dei nodi per descrivere i nodi che vuoi eseguire il provisioning.

  • Tipo di regola del node pool: nei cluster GKE Standard, fornisce un elenco di node pool creati manualmente associati alla ComputeClass in cui GKE deve eseguire il provisioning dei nodi.

Regole di priorità dichiarative

Con le regole di priorità dichiarative, puoi specificare le proprietà della macchina, ad esempio famiglia o tipo di macchina, VM spot, opzioni di acceleratore, opzioni di archiviazione, prenotazioni e requisiti minimi di risorse, che GKE deve utilizzare durante il provisioning dei nodi. Per l'insieme completo di campi supportati, consulta il riferimento CRD ComputeClass.

configurazioni machineFamily

Il campo machineFamily accetta una serie di macchine Compute Engine come n4 o c4. Se non specificato, il valore predefinito è e2.

Puoi utilizzare altri spec.priorities campi insieme al campo machineFamily per definire in modo dichiarativo i requisiti di calcolo, ad esempio:

  • spot: VM spot. Il valore predefinito è false.
  • minCores: vCPU minime per nodo. Il valore predefinito è 0.
  • minMemoryGb: la memoria minima per nodo. Il valore predefinito è 0.
  • storage.bootDiskKMSKey: percorso della chiave Cloud Key Management Service da utilizzare per la crittografia del disco di avvio.
  • storage.secondaryBootDisks: dischi permanenti utilizzati per precaricare i nodi GKE con dati, ad esempio un modello di machine learning (ML) o un'immagine container. Richiede GKE 1.31.2-gke.1105000 o versioni successive. Per configurare un disco di avvio secondario da utilizzare per il cluster, vedi Configurare i dischi di avvio secondari.
    • storage.secondaryBootDisks.diskImageName: il nome dell'immagine disco da precaricare.
    • storage.secondaryBootDisks.project: il nome del progetto a cui appartiene l'immagine disco. Se questo valore non è specificato, il valore predefinito è il progetto del cluster.
    • storage.secondaryBootDisks.mode: la modalità in cui deve essere utilizzato il disco di avvio secondario. Se questo valore è impostato su CONTAINER_IMAGE_CACHE, il disco di avvio secondario viene utilizzato come cache dell'immagine container. Il valore deve essere uguale a CONTAINER_IMAGE_CACHE o MODE_UNSPECIFIED. Se questo valore non è specificato, il valore predefinito è MODE_UNSPECIFIED.
  • placement: i dettagli del posizionamento della macchina:

Il seguente esempio mostra una regola di priorità che utilizza machineFamily:

priorities:
- machineFamily: n4
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1
    secondaryBootDisks:
    - diskImageName: pytorch-mnist
      project: k8s-staging-jobset
Configurazioni machineType

Il campo machineType accetta un tipo di macchina predefinita di Compute Engine, come n4-standard-32, o una stringa di tipo di macchina personalizzata, come n4-custom-8-20480. L'utilizzo di tipi di macchine personalizzati richiede GKE 1.33.2-gke.1111000 o versioni successive.

Puoi specificare altri campi spec.priorities insieme al campo machineType per definire in modo dichiarativo i requisiti di calcolo, ad esempio:

  • spot: utilizza le VM spot. Il valore predefinito è false.
  • storage: Configura l'archiviazione dei nodi.
    • storage.bootDiskType: Tipo di disco di avvio. Su Autopilot è supportato solo il tipo pd-balanced di bootDiskType.
    • storage.bootDiskKMSKey: percorso della chiave Cloud KMS da utilizzare per la crittografia del disco di avvio.
    • storage.bootDiskSize: dimensioni in GB del disco di avvio del nodo.
    • storage.localSSDCount: numero di SSD locali da collegare al nodo. Se specificato, deve essere almeno pari a 1.

L'esempio seguente mostra una regola di priorità che utilizza machineType per il provisioning dei tipi di macchine n4-standard-32:

priorities:
- machineType: n4-standard-32
  spot: true
  storage:
    bootDiskType: pd-balanced
    bootDiskSize: 250
    localSSDCount: 2
    bootDiskKMSKey: projects/example/locations/us-central1/keyRings/example/cryptoKeys/key-1
Configurazione GPU

Per selezionare le GPU nelle regole di priorità, specifica il tipo, il conteggio e driverVersion (facoltativo) della GPU nel campo gpu di una regola di priorità. Sono supportati i seguenti campi:

Puoi anche specificare altri spec.priorities campi come VM spot, opzioni di archiviazione e prenotazioni in combinazione con i campi gpu.

Il seguente esempio mostra una regola per le GPU:

priorities:
- gpu:
    type: nvidia-l4
    count: 1
  storage:
    secondaryBootDisks:
    - diskImageName: big-llm
      project: k8s-llm
  spot: true
Configurazione TPU

Richiede GKE 1.31.2-gke.1518000 o versioni successive

Per selezionare le TPU nelle regole di priorità, specifica il tipo, il conteggio e la topologia della TPU nel campo tpu di una regola di priorità. I seguenti campi sono obbligatori:

Puoi anche specificare altri spec.priorities campi insieme al campo tpu nella regola di priorità, ad esempio:

  • spot: utilizza le VM spot. Il valore predefinito è false.
  • storage: Configura l'archiviazione dei nodi.
    • storage.bootDiskType: Tipo di disco di avvio.
    • storage.bootDiskKMSKey: percorso della chiave Cloud KMS da utilizzare per la crittografia del disco di avvio.
    • storage.bootDiskSize: dimensioni in GB del disco di avvio del nodo.
  • reservations: utilizza una prenotazione Compute Engine. Per i dettagli, consulta la sezione Utilizzare le prenotazioni di Compute Engine.

Il seguente esempio mostra una regola per le TPU:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-class
spec:
  priorities:
  - tpu:
      type: tpu-v5p-slice
      count: 4
      topology: 4x4x4
    reservations:
      specific:
      - name: tpu-reservation
        project: reservation-project
      affinity: Specific
  - spot: true
    tpu:
      type: tpu-v5p-slice
      count: 4
      topology: 4x4x4
  nodePoolAutoCreation:
    enabled: true

Questo esempio definisce il seguente comportamento di riserva:

  1. GKE tenta di eseguire il provisioning di uno slice TPU v5p multi-host a 16 nodi utilizzando una prenotazione Compute Engine condivisa denominata tpu-reservation dal progetto reservation-project.
  2. Se la prenotazione non ha TPU disponibili, GKE tenta di eseguire il provisioning di una sezione TPU v5p multi-host a 16 nodi in esecuzione su VM spot.
  3. Se nessuna delle regole precedenti può essere soddisfatta, GKE segue la logica descritta nella sezione Definisci il comportamento di scalabilità quando non si applicano regole di priorità.

Dopo aver eseguito il deployment di una ComputeClass personalizzata TPU nel cluster, seleziona la ComputeClass personalizzata nel workload:

Inoltre, per i carichi di lavoro TPU puoi:

Specifiche di acceleratori e forma della macchina

Le configurazioni di acceleratori dichiarativi non richiedono la specifica esplicita del campo machineType o machineFamily, a meno che non vengano utilizzati in combinazione con le prenotazioni.

Regole di priorità dei node pool

Il campo nodepools accetta un elenco di node pool esistenti su cui GKE tenta di creare pod in attesa. GKE non elabora i valori in questo campo in ordine. Non puoi utilizzare altri campi spec.priorities insieme al campo nodepools nello stesso elemento della regola di priorità perché le regole con il campo nodepools non sono dichiarative per natura. Questo campo è supportato solo in modalità GKE Standard. Per i dettagli sull'utilizzo, vedi Target specific node pools in a ComputeClass definition.

Come GKE crea i nodi utilizzando le regole di priorità

Quando esegui il deployment di un workload che richiede una ComputeClass e un nuovo nodo, GKE elabora l'elenco di regole nel campo priorities della specifica ComputeClass in ordine.

Ad esempio, considera la seguente specifica:

spec:
  ...
  priorities:
  - machineFamily: n4
    spot: true
    minCores: 64
  - machineFamily: n4
    spot: true
  - machineFamily: n4
    spot: false

Quando esegui il deployment di un workload che richiede una ComputeClass con queste regole di priorità, GKE abbina i nodi nel seguente modo:

  1. GKE posiziona i pod su tutti i nodi esistenti associati a questa ComputeClass.
  2. Se i nodi esistenti non possono ospitare i pod, GKE esegue il provisioning di nuovi nodi che utilizzano la serie di macchine N4, sono VM spot e hanno almeno 64 vCPU.
  3. Se le VM spot N4 con almeno 64 vCPU non sono disponibili nella regione, GKE esegue il provisioning di nuovi nodi che utilizzano VM spot N4 in grado di ospitare i pod, indipendentemente dal numero di core.
  4. Se nella regione non sono disponibili VM spot N4, GKE esegue il provisioning di nuove VM N4 on demand.
  5. Se nessuna delle regole precedenti può essere soddisfatta, GKE segue la logica descritta nella sezione Definisci il comportamento di scalabilità quando non si applicano regole di priorità.

Valori predefiniti per le regole prioritarie

Puoi impostare valori predefiniti per alcuni campi nelle regole di priorità della specifica ComputeClass. Questi valori predefiniti vengono applicati se i campi corrispondenti in una regola specifica vengono omessi. Puoi impostare questi valori predefiniti utilizzando il campo priorityDefaults nella specifica ComputeClass.

Il campo priorityDefaults presenta le seguenti limitazioni:

  • Richiede la versione 1.32.1-gke.1729000 di GKE o versioni successive.
  • Non è compatibile con la regola di priorità nodepools, che non contiene campi.

Per informazioni dettagliate sui tipi di valori predefiniti che puoi impostare, consulta la sezione priorityDefaults nella CustomResourceDefinition ComputeClass.

Node pool GKE Standard e ComputeClass

Se utilizzi la modalità GKE Standard, potresti dover eseguire la configurazione manuale per assicurarti che i pod ComputeClass vengano pianificati come previsto.

Configura i node pool creati manualmente per l'utilizzo di ComputeClass

Se i tuoi cluster GKE Standard hanno node pool che hai creato manualmente senza il provisioning automatico dei nodi, devi configurare questi node pool per associarli a ComputeClass specifiche. GKE pianifica solo i pod che richiedono una ComputeClass specifica sui nodi nei pool di nodi che associ a quella ComputeClass. Questo requisito non si applica a una ComputeClass che configuri come impostazione predefinita a livello di cluster.

I pool di nodi in modalità GKE Autopilot e in modalità GKE Standard creati dal provisioning automatico dei nodi eseguono automaticamente questa configurazione.

Per associare un pool di nodi creato manualmente a una ComputeClass, aggiungi etichette dei nodi e taint dei nodi al pool di nodi durante la creazione o l'aggiornamento specificando i flag --node-labels e --node-taints, come segue:

  • Etichetta nodo: cloud.google.com/compute-class=COMPUTE_CLASS
  • Taint: cloud.google.com/compute-class=COMPUTE_CLASS:NoSchedule

In questi attributi, COMPUTE_CLASS è il nome della tua ComputeClass personalizzata.

Ad esempio, i seguenti comandi aggiornano insieme un pool di nodi esistente e lo associano alla ComputeClass dev-class:

gcloud container node-pools update dev-pool \
    --cluster=example-cluster \
    --node-labels="cloud.google.com/compute-class=dev-class"

gcloud container node-pools update dev-pool \
    --cluster=example-cluster \
    --node-taints="cloud.google.com/compute-class=dev-class:NoSchedule"

Puoi associare ogni pool di nodi nel cluster a una ComputeClass personalizzata. I pod che GKE pianifica solo su questi node pool creati manualmente attivano la creazione di nodi all'interno di questi node pool durante gli eventi di scalabilità automatica.

Provisioning automatico dei nodi e ComputeClasses

Puoi utilizzare il provisioning automatico dei nodi con una ComputeClass personalizzata per consentire a GKE di creare ed eliminare automaticamente i node pool in base alle regole di priorità.

Per utilizzare il provisioning automatico dei nodi con una ComputeClass, devi:

  1. Assicurati di aver attivato il provisioning automatico dei nodi nel cluster.
  2. Aggiungi il campo nodePoolAutoCreation con il valore enabled: true alla specifica ComputeClass.

GKE può quindi posizionare i pod che utilizzano ComputeClass che configurano il provisioning automatico dei nodi sui nuovi node pool. GKE decide se aumentare le dimensioni di unpool di nodil esistente o crearne uno nuovo in base a fattori quali le dimensioni dei cluster e i requisiti dei pod. I pod con ComputeClass che non configurano il provisioning automatico dei nodi continuano a scalare solo i node pool esistenti.

Puoi utilizzare ComputeClass che interagiscono con il provisioning automatico dei nodi insieme a ComputeClass che interagiscono con i node pool creati manualmente nello stesso cluster.

Considera le seguenti interazioni con il provisioning automatico dei nodi:

  • Non puoi utilizzare i selettori di nodi famiglia di macchine o VM spot perché questi selettori sono in conflitto con il comportamento di ComputeClass. GKE rifiuta tutti i pod che richiedono una ComputeClass e anche VM spot o serie di macchine specifiche.

  • Se imposti una ComputeClass predefinita per il cluster, i pod che utilizzano un selettore di nodi della famiglia di macchine attivano la creazione di nodi solo per quella classe predefinita in una delle seguenti situazioni:

    • I pod selezionano una famiglia di macchine che corrisponde a una delle regole di priorità nella classe predefinita a livello di cluster. Ad esempio, un pod che seleziona istanze N4 attiva la creazione di nodi se la classe predefinita a livello di cluster ha una regola di priorità per le istanze N4.
    • La ComputeClass predefinita a livello di cluster ha un valore di ScaleUpAnyway nel campo spec.whenUnsatisfiable. Anche se i pod selezionano una famiglia di macchine che non rientra nelle priorità di ComputeClass, GKE crea nuovi nodi con quella famiglia di macchine.

    I pod che selezionano una famiglia di macchine non inclusa nelle priorità della classe predefinita a livello di cluster non attivano la creazione di nodi se ComputeClass ha un valore di DoNotScaleUp nel campo whenUnsatisfiable.

  • Puoi configurare il provisioning automatico dei nodi per le ComputeClass che utilizzano il campo nodepools per fare riferimento ai pool di nodi esistenti. Il provisioning automatico dei nodi elabora le priorità in ordine e tenta di scalare i node pool esistenti per inserire i pod.

Considera il seguente esempio per un cluster con pool di nodi creati manualmente e il provisioning automatico dei nodi:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - nodepools: [manually-created-pool]
  - machineFamily: n4
  - machineFamily: c4
  nodePoolAutoCreation:
    enabled: true

In questo esempio, GKE tenta di eseguire le seguenti operazioni:

  1. Crea nuovi nodi nel pool di nodi manually-created-pool.
  2. Esegui il provisioning dei nodi N4, nei pool di nodi N4 esistenti o creando un nuovo node pool.
  3. Se GKE non riesce a creare nodi N4, tenta di scalare i pool di nodi C4 esistenti o di crearne di nuovi.

Target di pool di nodi specifici in una definizione ComputeClass

Il campo priorities.nodepools consente di specificare un elenco di node pool creati manualmente in cui GKE tenta di pianificare i pod senza un ordine specifico nei cluster GKE Standard che utilizzano la scalabilità automatica del cluster. Questo campo supporta solo un elenco di node pool. Non puoi specificare proprietà aggiuntive della macchina, come la serie di macchine, nella stessa regola di priorità. Quando esegui il deployment di un carico di lavoro che richiede una ComputeClass con node pool denominati, GKE tenta di pianificare i pod in attesa in questi node pool. GKE potrebbe creare nuovi nodi in questi node pool per posizionare i pod.

I node pool specificati nel campo priorities.nodepools devono essere associati a ComputeClass utilizzando le etichette e i taint dei nodi, come descritto nella sezione Configurare i node pool creati manualmente per ComputeClass.

L'elenco dei pool di nodi specificati nel campo nodepools non ha priorità. Per configurare un ordine di fallback per i pool di nodi denominati, devi specificare più elementi priorities.nodepools separati. Ad esempio, considera la seguente specifica:

spec:
  ...
  priorities:
  - nodepools: [pool1, pool2]
  - nodepools: [pool3]

In questo esempio, GKE tenta innanzitutto di inserire i pod in attesa che richiedono questa ComputeClass sui nodi esistenti nei pool di nodi etichettati con la ComputeClass. Se i nodi esistenti non sono disponibili, GKE tenta di eseguire il provisioning di nuovi nodi in pool1 o pool2. Se GKE non riesce a eseguire il provisioning di nuovi nodi in questi pool di nodi, tenta di eseguire il provisioning di nuovi pod in pool3.

Definisci il comportamento di scalabilità quando non vengono applicate regole di priorità

La risorsa personalizzata ComputeClass ti consente di specificare cosa deve fare GKE se non sono presenti nodi che soddisfano una delle regole di priorità. Il campo whenUnsatisfiable nella specifica supporta i seguenti valori.

  • ScaleUpAnyway: crea un nuovo nodo che utilizzi la configurazione predefinita della macchina del cluster. Nelle versioni di GKE precedenti alla 1.33, questo è il comportamento predefinito se ometti questo campo.

    GKE esegue una delle seguenti azioni:

    • Nei cluster Autopilot, GKE posiziona il pod su un nodo nuovo o esistente, indipendentemente dalla configurazione della macchina del nodo.
    • Nei cluster Standard che non utilizzano il provisioning automatico dei nodi, GKE tenta di scalare orizzontalmente qualsiasi pool di nodi creato manualmente che definisce un'etichetta e un taint corrispondenti a una determinata ComputeClass.
    • Nei cluster Standard che utilizzano il provisioning automatico dei nodi, GKE potrebbe creare un nuovopool di nodil che utilizza la serie di macchine E2 per posizionare il pod.

  • DoNotScaleUp: lascia il pod nello stato Pending finché non è disponibile un nodo che soddisfi i requisiti di ComputeClass. In GKE versione 1.33 e successive, questo è il comportamento predefinito se ometti questo campo.

Richiedere una policy di posizionamento

A partire dalla versione 1.33.2-gke.1335000 di GKE, nei cluster GKE Autopilot puoi utilizzare il posizionamento compatto con un criterio di posizionamento o un criterio di workload personalizzato. Per saperne di più, consulta Confronto tra la policy di posizionamento compatto e la policy del workload.

Sia la policy di posizionamento che la policy del workload posizionano i nodi fisicamente vicini tra loro per ridurre la latenza di rete. Per utilizzare una policy specifica, fornisci il relativo nome in un campo policyName. Il criterio deve essere un criterio delle risorse Compute Engine che esiste già nel progetto GKE.

Considera l'esempio seguente:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
    placement:
      policyName: my-placement-policy
  nodePoolAutoCreation:
    enabled: true

In questa configurazione, GKE applica la policy di posizionamento compatto per tutti i carichi di lavoro che utilizzano questa ComputeClass e esegue il provisioning dei relativi nodi in base alla policy di risorse esistente denominata my-placement-policy.

Imposta i parametri di scalabilità automatica per il consolidamento dei nodi

Per impostazione predefinita, GKE rimuove i nodi sottoutilizzati eseguendo i carichi di lavoro, consolidandoli su altri nodi con capacità. Per tutte le ComputeClass, questo è il comportamento predefinito perché tutti i cluster che utilizzano le ComputeClass devono utilizzare il gestore della scalabilità automatica dei cluster o sono cluster Autopilot. Durante un consolidamento dei nodi, GKE svuota un nodo sottoutilizzato, ricrea i carichi di lavoro su un altro nodo ed elimina il nodo svuotato.

I tempi e i criteri per la rimozione dei nodi dipendono dal profilo di scalabilità automatica. Puoi ottimizzare le soglie di sottoutilizzo delle risorse che attivano la rimozione dei nodi e il consolidamento dei workload utilizzando la sezione autoscalingPolicy nella definizione di ComputeClass personalizzata. Puoi ottimizzare i seguenti parametri:

  • consolidationDelayMinutes: il numero di minuti dopo i quali GKE rimuove i nodi sottoutilizzati
  • consolidationThreshold: la soglia di utilizzo di CPU e memoria come percentuale delle risorse disponibili del nodo. GKE prende in considerazione la rimozione dei nodi solo se l'utilizzo delle risorse è inferiore a questa soglia.
  • gpuConsolidationThreshold: la soglia di utilizzo della GPU come percentuale delle risorse disponibili del nodo. GKE prende in considerazione la rimozione dei nodi solo se l'utilizzo delle risorse è inferiore a questa soglia. Valuta la possibilità di impostare questo valore su 100 o 0 in modo che GKE consolidi tutti i nodi che non utilizzano al 100% le GPU collegate.

Considera l'esempio seguente:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
  - machineFamily: c4
  autoscalingPolicy:
    consolidationDelayMinutes: 5
    consolidationThreshold: 70

In questa configurazione, GKE rimuove i nodi inutilizzati dopo cinque minuti e i nodi diventano candidati al consolidamento solo se l'utilizzo di CPU e memoria è inferiore al 70%.

Configura la migrazione attiva ai nodi con priorità più alta

La migrazione attiva è una funzionalità di scalabilità automatica facoltativa nelle ComputeClass personalizzate che sostituisce automaticamente i nodi esistenti che si trovano più in basso in un elenco di priorità di riserva di ComputeClass con nuovi nodi che si trovano più in alto in questo elenco di priorità. In questo modo, tutti i pod in esecuzione verranno eseguiti sui nodi preferiti per quella ComputeClass, anche se inizialmente GKE ha dovuto eseguirli su nodi meno preferiti.

Quando si verifica una migrazione attiva, GKE crea nuovi nodi in base alle regole di priorità di ComputeClass, quindi svuota ed elimina i nodi obsoleti a priorità inferiore. La migrazione avviene gradualmente per ridurre al minimo l'interruzione del workload. La migrazione attiva presenta le seguenti considerazioni:

  • La migrazione attiva non esegue la migrazione dei dati archiviati in uno spazio di archiviazione permanente, come i dischi permanenti Compute Engine. Per ridurre al minimo il rischio di perdita di dati, non attivare la migrazione attiva in ComputeClass utilizzate dai carichi di lavoro stateful.
  • Se hai abilitato il provisioning automatico dei nodi nei cluster Standard, la migrazione attiva potrebbe attivare la creazione di nuovi node pool se quelli esistenti non soddisfano i criteri di priorità più elevata definiti nella classe di calcolo personalizzata.
  • La migrazione attiva non sostituisce i nodi che non possono essere rimossi. Ad esempio, la migrazione attiva non sostituisce un nodo se ciò viola l'impostazione del pool di nodi --min-nodes.
  • Per evitare interruzioni critiche del carico di lavoro, la migrazione attiva non sposta i seguenti pod:
    • Pod che impostano un budget di interruzione dei pod, se lo spostamento supererebbe il budget di interruzione dei pod.
    • Pod con l'annotazione cluster-autoscaler.kubernetes.io/safe-to-evict: "false".
  • I carichi di lavoro che utilizzano volumi permanenti con risorse di zona come Hyperdisk potrebbero non funzionare bene con la migrazione attiva. Le limitazioni zonali e le limitazioni del tipo di macchina di alcuni prodotti Hyperdisk possono ridurre l'efficacia della migrazione attiva. Inoltre, alcuni carichi di lavoro stateful potrebbero non tollerare l'interruzione causata dalla migrazione attiva.
  • Se aggiorni una ComputeClass esistente per abilitare la migrazione attiva, GKE esegue la migrazione dei pod esistenti ai nodi con priorità più alta nel tempo.

Considera la seguente specifica ComputeClass, che assegna la priorità ai nodi N4 rispetto ai nodi C4:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - machineFamily: n4
  - machineFamily: c4
  activeMigration:
    optimizeRulePriority: true

Se i nodi N4 non erano disponibili quando hai eseguito il deployment di un pod con questa ComputeClass, GKE avrebbe utilizzato i nodi C4 come opzione di riserva. Se i nodi N4 diventano disponibili per il provisioning in un secondo momento, ad esempio se la quota aumenta o se le VM N4 diventano disponibili nella tua località, GKE crea un nuovo nodo N4 e migra gradualmente il pod dal nodo C4 esistente al nuovo nodo N4. GKE elimina quindi il nodo C4 obsoleto.

Consumare le prenotazioni di Compute Engine

Disponibile in GKE 1.31.1-gke.2105000 e versioni successive

Se utilizzi le prenotazioni di capacità di Compute Engine per ottenere un livello di garanzia più elevato della disponibilità hardware in zoneGoogle Cloud specifiche, puoi configurare ogni priorità di fallback nella tua ComputeClass personalizzata in modo che GKE utilizzi le prenotazioni durante la creazione di nuovi nodi.

L'utilizzo delle prenotazioni nelle ComputeClass personalizzate deve soddisfare i seguenti requisiti:

  • I cluster in modalità Standard devono utilizzare il provisioning automatico dei nodi affinché GKE utilizzi le prenotazioni per creare nuovi nodi. Per i dettagli, consulta la sezione Provisioning automatico dei nodi e ComputeClass. Puoi anche continuare a utilizzare le prenotazioni quando crei manualmente i pool di nodi nel cluster.
  • Le prenotazioni non TPU possono essere utilizzate solo quando è definito machineType o machineFamily.
  • Le ComputeClass che configurano gli SSD locali devono utilizzare la regola di priorità machineType, non machineFamily. Per i dettagli, vedi la sezione Tipo di regola machineType.
  • ComputeClasses che specificano prenotazioni per un machineType a cui sono collegati SSD locali devono includere esplicitamente un campo localSSDCount:.

Prendi in considerazione la seguente specifica di ComputeClass di esempio, che assegna la priorità a una prenotazione condivisa specifica da utilizzare durante il provisioning delle istanze a3-highgpu-1g. Se i tipi di istanza con priorità non sono disponibili, GKE esegue il failover su eventuali prenotazioni corrispondenti nella specifica:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: accelerator-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineType: a3-highgpu-1g
    storage:
      localSSDCount: 2
    gpu:
      type: nvidia-h100-80gb
      count: 1
    reservations:
      specific:
      - name: a3-shared-reservation
        project: reservation-project
      affinity: Specific
  - machineType: a3-highgpu-1g
    storage:
      localSSDCount: 2
    gpu:
      type: nvidia-h100-80gb
      count: 1
    reservations:
      affinity: AnyBestEffort
  whenUnsatisfiable: DoNotScaleUp

Se esegui il deployment di un pod che utilizza accelerator-reservations ComputeClass, GKE tenta innanzitutto di utilizzare la prenotazione a3-shared-reservation quando crea nuove istanze a3-highgpu-1g per eseguire il pod. Se questa prenotazione specifica non ha capacità disponibile, GKE tenta di scalare le istanze a3-highgpu-1g utilizzando qualsiasi prenotazione corrispondente. Se non sono accessibili prenotazioni, GKE esegue il failover alle VM spot a3-highgpu-1g. Infine, se non sono disponibili VM spot, l'operazione di scalabilità non va a buon fine.

In questo esempio, entrambe le regole di priorità con riferimenti alla prenotazione richiedono esplicitamente il campo localSSDCount: perché la forma della macchina a3-highgpu-1g include SSD locali.

L'esempio seguente mostra una prenotazione specifica condivisa, che esegue il failover sulle VM spot e infine sulle VM on demand:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: shared-specific-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: n4
    reservations:
      specific:
      - name: n4-shared-reservation
        project: reservation-project
      affinity: Specific
  - machineFamily: n4
    spot: true
  - machineFamily: n4
  whenUnsatisfiable: DoNotScaleUp

Puoi utilizzare i seguenti tipi di prenotazioni:

  • Prenotazioni specifiche per un singolo progetto: configura i seguenti campi:

    • reservations.specific.name: il nome della prenotazione.
    • reservations.affinity: deve essere Specific.

  • Prenotazioni condivise specifiche: configura i seguenti campi:

    • reservations.specific.name: il nome della prenotazione.
    • reservations.specific.project: l'ID progetto del progetto proprietario della prenotazione.
    • reservations.affinity: deve essere Specific.

  • Eventuali prenotazioni corrispondenti: configura i seguenti campi:

    • reservations.affinity: deve essere AnyBestEffort.
    • Non impostare un nome o un progetto per la prenotazione.

Le prenotazioni di TPU richiedono un'affinità specifica. reservations.affinity: AnyBestEffort non è supportato.

Se GKE non riesce a trovare capacità disponibile in una prenotazione, il comportamento risultante dipende dal tipo di prenotazione selezionato nella regola di priorità ComputeClass, come segue:

  • Prenotazioni specifiche: GKE prova la regola di priorità successiva in ComputeClass.
  • Eventuali prenotazioni corrispondenti: GKE tenta di eseguire il provisioning di un nodo on demand che soddisfi i requisiti di questa regola di priorità. Se GKE non riesce a eseguire il provisioning di un nodo on demand, GKE prova la regola di priorità successiva in ComputeClass.

Se GKE non riesce a soddisfare i requisiti di una delle regole di priorità per ComputeClass, si verifica il comportamento quando non si applicano regole.

Consumare blocchi di prenotazioni specifici

A partire dalla versione 1.31.4-gke.1072000 di GKE, puoi scegliere come target un blocco di prenotazione specifico all'interno di una prenotazione supportata dall'hardware. Questa funzionalità è disponibile per i tipi di macchine A3 Ultra e A4.

Per utilizzare un blocco di prenotazione specifico, configura la risorsa ComputeClass come mostrato in questo esempio:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: specific-reservations
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineFamily: a3
    gpu:
      type: nvidia-h200-141gb
      count: 8
    reservations:
      specific:
      - name: a3ultra-specific-reservation
        reservationBlock:
          name: RESERVATION_BLOCK_NAME
      affinity: Specific

Sostituisci RESERVATION_BLOCK_NAME con il nome del blocco di prenotazione di destinazione.

A partire dalla versione 1.33.1-gke.1788000 di GKE, puoi scegliere come target un blocco secondario di prenotazioni specifico all'interno di un blocco di prenotazioni. Questa funzionalità è disponibile per il tipo di macchina A4X.

Per utilizzare un blocco secondario di prenotazione specifico, configura la risorsa ComputeClass come mostrato nell'esempio in Utilizzare blocchi secondari di prenotazione specifici.

Quando utilizzi questa funzionalità, tieni presente quanto segue:

  • Queste funzionalità si applicano solo a prenotazioni specifiche in un progetto singolo o condiviso.

Personalizzare la configurazione del sistema di nodi

Puoi personalizzare determinati parametri nel kubelet e nel kernel Linux utilizzando il campo nodeSystemConfig nella specifica ComputeClass. Puoi specificare questo campo in qualsiasi regola di priorità che definisce una serie di macchine o un tipo di macchina Compute Engine. Puoi anche impostare valori globali predefiniti per qualsiasi campo di configurazione del sistema dei nodi omesso nelle regole di priorità aggiungendo il campo nodeSystemConfig al campo priorityDefaults nella classe di calcolo.

Questa funzionalità è disponibile in GKE versione 1.32.1-gke.1729000 e successive.

Per maggiori informazioni, consulta le seguenti pagine:

ComputeClass predefinite per cluster e spazi dei nomi

Puoi configurare GKE in modo che applichi una ComputeClass per impostazione predefinita ai pod che non selezionano una ComputeClass specifica. Puoi definire una ComputeClass predefinita per spazi dei nomi specifici o per un intero cluster. Per ulteriori informazioni su come configurare i cluster o gli spazi dei nomi con una classe predefinita, consulta Applicare ComputeClass ai pod per impostazione predefinita.

Raggruppa i node pool

A partire dalla versione 1.32.2-gke.1359000 di GKE, puoi raggruppare più node pool in un'unica unità logica chiamata raccolta utilizzando il campo nodePoolGroup nella specifica ComputeClass. Questo raggruppamento ti consente di applicare configurazioni condivise a molti pool di nodi.

Raccolta multi-host TPU

Puoi raggruppare il deployment multi-host della TPU per impostare un obiettivo del livello di servizio (SLO) in tutti i node pool all'interno della raccolta. Per raggruppare i pool di nodi, specifica il nome del gruppo nel campo nodePoolGroup. Tutti i pool di nodi di cui è stato eseguito il provisioning utilizzando questa ComputeClass appartengono allo stesso gruppo.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tpu-multi-host-collection
spec:
  nodePoolGroup:
    name: my-tpu-collection
  ...

Per ulteriori informazioni, consulta le seguenti risorse:

Configurazione del node pool

Il campo nodePoolConfig nella specifica ComputeClass ti consente di applicare una configurazione che si riflette in tutti i nodi all'interno dei pool di nodi creati utilizzando quella classe.

Specifica il tipo di immagine

Puoi specificare il sistema operativo di base per i nodi nel pool di nodi utilizzando il campo imageType. Questo campo consente di scegliere un tipo di immagine per i node pool che verranno eseguiti sui nodi. Se ometti questo campo, il valore predefinito è cos_containerd. L'esempio seguente mostra come specificare imageType in ComputeClass:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-node-pool-config
spec:
  nodePoolConfig:
    imageType: cos_containerd

Per saperne di più, consulta la sezione Immagini dei nodi.

Service account

Il campo serviceAccount specifica l'account di servizio Google Cloud utilizzato dai nodi all'interno dei pool di nodi gestiti da ComputeClass. L'esempio seguente mostra come specificare serviceAccount in ComputeClass:

spec:
  nodePoolConfig:
    serviceAccount: my-service-account@my-project.iam.gserviceaccount.com

Per saperne di più, consulta Informazioni sui service account in GKE.

Definisci il tipo di workload per lo SLO TPU

A partire dalla versione 1.32.2-gke.1359000 di GKE, puoi definire l'obiettivo del livello di servizio (SLO) per i carichi di lavoro TPU utilizzando il campo workloadType all'interno di nodePoolConfig. Il valore in questo campo indica a GKE l'utilizzo previsto per le risorse TPU. Il campo workloadType supporta i seguenti valori:

  • HIGH_AVAILABILITY: utilizza questo valore per i carichi di lavoro incentrati sulla disponibilità, ad esempio l'inferenza, per limitare e semplificare le interruzioni.
  • HIGH_THROUGHPUT: utilizza questo valore per i job batch o di addestramento che richiedono l'esecuzione della maggior parte dell'infrastruttura sottostante per progredire. Questo valore può essere utilizzato solo se viene specificato anche nodePoolGroup.

L'esempio seguente definisce una ComputeClass per una raccolta di TPU multi-host ottimizzata per i carichi di lavoro di inferenza ad alta disponibilità.

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: multi-host-inference
spec:
  nodePoolGroup:
    name: my-inference-collection
  nodePoolConfig:
    workloadType: HIGH_AVAILABILITY
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - tpu:
      type: tpu-v6e-slice
      topology: 2x4

Per maggiori informazioni, consulta le seguenti pagine:

Richiedere ComputeClass nei carichi di lavoro

Per utilizzare una ComputeClass personalizzata, il pod deve richiederla esplicitamente utilizzando un nodeSelector nella specifica del pod. Se vuoi, puoi impostare una ComputeClass come predefinita per uno spazio dei nomi Kubernetes specifico. I pod in questo spazio dei nomi utilizzano ComputeClass, a meno che non ne richiedano una diversa.

Ad esempio, il seguente manifest richiede ComputeClass cost-optimized:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: custom-workload
spec:
  replicas: 2
  selector:
    matchLabels:
      app: custom-workload
  template:
    metadata:
      labels:
        app: custom-workload
    spec:
      nodeSelector:
        cloud.google.com/compute-class: cost-optimized
      containers:
      - name: test
        image: gcr.io/google_containers/pause
        resources:
          requests:
            cpu: 1.5
            memory: "4Gi"

Selettori dei nodi per le etichette dei nodi di sistema

GKE aggiunge etichette di sistema ai nodi per identificarli in base a criteri come il tipo di macchina, gli acceleratori hardware collegati o il tipo di disco di avvio. Queste etichette di sistema hanno uno dei seguenti prefissi nella chiave dell'etichetta:

  • k8s.io
  • cloud.google.com
  • gke.io

In GKE versione 1.32.3-gke.1499000 e successive, puoi eseguire il deployment di carichi di lavoro che utilizzano un selettore di nodi per selezionare le etichette di sistema e una ComputeClass contemporaneamente. Se selezioni le etichette di sistema nei pod che selezionano le classi di calcolo, verifica che la pianificazione dei pod avvenga come previsto. Un conflitto tra la configurazione di una ComputeClass e i selettori di nodi in un pod potrebbe causare problemi come i seguenti:

  • GKE non può creare nodi che utilizzano la configurazione con la priorità più alta per ComputeClass.
  • Il pod rimane nello stato Pending.

GKE rifiuta anche i pod che selezionano etichette di sistema con un campo corrispondente nella specifica ComputeClass. Quando utilizzi le classi di calcolo, aggiorna i workload per rimuovere le seguenti etichette dai selettori dei nodi e configura il campo corrispondente nelle ComputeClass che crei:

Etichetta nodo Campo ComputeClass
cloud.google.com/machine-family priorities.machineFamily
cloud.google.com/machine-type priorities.machineType
cloud.google.com/gke-spot priorities.spot
cloud.google.com/gke-accelerator priorities.gpu.type
cloud.google.com/gke-gpu-driver-version priorities.gpu.driverVersion
cloud.google.com/reservation-name priorities.reservations.specific.name
cloud.google.com/reservation-project priorities.reservations.specific.project
cloud.google.com/reservation-affinity priorities.reservations.affinity
cloud.google.com/gke-ephemeral-storage-local-ssd priorities.storage.localSSDCount
cloud.google.com/gke-boot-disk priorities.storage.bootDiskType
cloud.google.com/gke-boot-disk-size priorities.storage.bootDiskSize
cloud.google.com/gke-node-pool-group-name nodePoolGroup.name
cloud.google.com/gke-workload-type nodePoolConfig.workloadType

Passaggi successivi