Informazioni su ComputeClass personalizzate

Puoi creare i tuoi ComputeClasses per controllare le proprietà dei nodi di cui Google Kubernetes Engine (GKE) esegue il provisioning durante la scalabilità automatica del cluster. Questo documento è rivolto agli amministratori della piattaforma che vogliono definire in modo dichiarativo i profili di scalabilità automatica per i nodi, in modo che carichi di lavoro 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 workload durante gli eventi di scalabilità automatica. Le classi ComputeClasses possono avere come target ottimizzazioni specifiche, come il provisioning di nodi ad alte prestazioni o l'assegnazione della priorità a configurazioni ottimizzate in termini di costi per ridurre i costi di esecuzione. Le ComputeClass personalizzate ti consentono di definire profili che GKE utilizza per scalare automaticamente i nodi in modo da soddisfare con precisione i requisiti di workload specifici.

Le ComputeClass sono disponibili per l'utilizzo in GKE modalità Autopilot e modalità 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 sono disponibili per la configurazione e l'utilizzo in tutti i cluster GKE idonei per impostazione predefinita.

Vantaggi delle classi ComputeClasses personalizzate

Le classi ComputeClasses personalizzate offrono i seguenti vantaggi:

  • Priorità di calcolo di fallback: definisci una gerarchia di configurazioni dei nodi in ogni ComputeClass a cui GKE deve dare la priorità. Se la configurazione preferita non è disponibile, GKE sceglie automaticamente la configurazione successiva nella gerarchia. Questo modello di riserva contribuisce a garantire che, anche quando le risorse di computing non sono disponibili, i workload vengano comunque 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 dei nodi durante lo scale up.
  • Configurazione dichiarativa dell'infrastruttura: adotta un approccio dichiarativo alla gestione dell'infrastruttura in modo che GKE crei automaticamente i nodi che corrispondono ai requisiti specifici del tuo workload.
  • Migrazione attiva: se nella tua località diventano disponibili risorse di computing per una configurazione della macchina più preferita, GKE esegue automaticamente la migrazione dei workload ai nuovi nodi che utilizzano la configurazione preferita.
  • Ottimizzazione dei costi: dai la priorità ai tipi di nodi 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 workload 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 disponibile e fa lo scale down del nodo sottoutilizzato.
  • Capacità minima dichiarativa: mantieni in modo proattivo un numero minimo di nodi di questa ComputeClass nel tuo cluster, il che contribuisce a garantire che la capacità sia disponibile per i workload critici.

Casi d'uso per ComputeClass personalizzate

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

  • Vuoi eseguire i tuoi workload AI/ML su configurazioni specifiche di GPU o TPU.
  • Vuoi impostare configurazioni hardware predefinite per i workload eseguiti da team specifici, eliminando l'overhead per gli operatori delle applicazioni.
  • Esegui workload 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 affidabilità.
  • Vuoi che GKE utilizzi in modo gerarchico configurazioni hardware specifiche durante l'indisponibilità delle risorse di computing, in modo che i tuoi workload 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 prenotazioni di capacità di Compute Engine devono essere utilizzate da GKE per eseguire il provisioning di nuovi nodi per workload 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 impostala come predefinita per uno spazio dei nomi Kubernetes. Quando un workload corrispondente richiede una nuova infrastruttura, GKE esegue il provisioning di nuovi nodi in linea con le priorità impostate nella definizione di ComputeClass.

Gli attributi che imposti in ComputeClasses definiscono il modo in cui GKE configura i nuovi nodi per l'esecuzione dei workload. Quando modifichi una ComputeClass esistente, tutti i nodi futuri creati da GKE per quella ComputeClass utilizzano la configurazione modificata. GKE non modifica retroattivamente la configurazione dei nodi esistenti in base alle tue modifiche.

Le classi ComputeClasses 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 se i nodi esistenti sono disponibili in varie priorità.

Per assicurarti che le tue ComputeClass personalizzate siano ottimizzate per il tuo parco risorse, tieni presente le seguenti linee guida:

  • Comprendi i requisiti di computing del tuo parco risorse, inclusi eventuali requisiti hardware specifici per l'applicazione.
  • Scegli un tema che guidi la progettazione di ogni ComputeClass. Ad esempio, una ComputeClass ottimizzata per le prestazioni potrebbe avere una strategia di riserva che utilizza solo tipi di macchine con CPU elevata.
  • Decidi la famiglia e la serie di macchine Compute Engine più adatte ai tuoi workload. Per maggiori dettagli, consulta 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 carichi di lavoro vengano sempre eseguiti su nodi che utilizzano configurazioni della macchina simili. Ad esempio, se la serie di macchine N4 non è disponibile, puoi eseguire il failover sulle macchine C3.

Visualizza la definizione completa della risorsa personalizzata

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

Pianifica una ComputeClass personalizzata

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

  1. Scegli le priorità di computing di riserva: definisci una serie di regole che regolano le proprietà dei nodi che GKE crea per ComputeClass.
  2. Configura i node pool e le classi ComputeClass di GKE Standard: per i cluster in modalità Standard, esegui i passaggi di configurazione richiesti per utilizzare la classe ComputeClass con i node pool.
  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 workload e rimuovere i nodi sottoutilizzati.
  5. Configura la migrazione attiva ai nodi con priorità più alta: facoltativamente, indica a GKE di spostare i workload sui nodi preferiti man mano che l'hardware diventa disponibile.
  6. Consuma prenotazioni Compute Engine: facoltativamente, indica a GKE di consumare le prenotazioni zonali Compute Engine esistenti quando crei nuovi nodi.
  7. Provisiona un numero minimo di nodi: facoltativamente, indica a GKE di mantenere un numero minimo di nodi nel cluster.

Scegli le priorità di computing 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 quali l'esaurimento delle risorse e le limitazioni di quota.

Puoi creare una strategia di riserva definendo un elenco di regole di priorità nel campo priorities nella specifica ComputeClass. Ogni regola di priorità può richiedere nodi in uno dei seguenti modi:

  • Proprietà dei nodi: definisci le proprietà dei nodi su cui vuoi eseguire i pod, ad esempio le famiglie di macchine da utilizzare. Quando un pod attiva un'operazione di scalabilità verticale, GKE tenta di creare un nodo con queste proprietà. Ogni regola di priorità deve specificare un tipo di hardware da eseguire il provisioning, come descritto nella sezione Proprietà del nodo di primo livello per le regole di priorità.

  • Selezione del node pool: nei cluster GKE Standard, specifica i nomi dei node pool esistenti da associare a ComputeClass. Quando un pod attiva un'operazione di scale up, GKE tenta di posizionarlo in questi pool di nodi. Le regole di priorità che selezionano i pool di nodi non supportano altri campi. Per saperne di più, consulta la sezione Pool di nodi GKE Standard e ComputeClasses.

Per impostazione predefinita, quando è necessario un nuovo nodo per un pod in entrata che seleziona una ComputeClass, GKE tenta di creare nodi nell'ordine in cui le regole di priorità vengono visualizzate nel manifest ComputeClass. In GKE versione 1.35.2-gke.1842000 e successive, puoi anche impostare esplicitamente un punteggio per ogni regola di priorità in una ComputeClass utilizzando il campo priorityScore, nel qual caso GKE elabora le regole in ordine dal punteggio più alto a quello più basso. Se tutte le regole di priorità in una ComputeClass sono esaurite, GKE crea nodi in base al comportamento descritto in Definisci il comportamento di scalabilità quando non si applicano regole di priorità.

Punteggi delle regole di priorità

Richiede GKE 1.35.2-gke.1842000 o versioni successive.

Per un controllo granulare dell'ordine in cui GKE elabora le regole di priorità per una ComputeClass, utilizza il campo priorityScore nelle regole. Durante la scalabilità, GKE elabora le regole di priorità in base al punteggio, con valori di punteggio più elevati che hanno una priorità maggiore rispetto ai valori più bassi.

Il campo priorityScore ha le seguenti proprietà:

  • Il campo accetta un valore intero con un valore minimo di 1 e un valore massimo di 1000.
  • Devi utilizzare il campo priorityScore in tutte le regole di priorità o in nessuna.

  • Puoi impostare lo stesso punteggio di priorità per un massimo di tre regole distinte. Durante lo scaling, GKE elabora insieme le regole che hanno lo stesso punteggio. GKE sceglie una regola specifica da utilizzare in base ai criteri operativi del gestore della scalabilità automatica dei cluster.

    Le regole raggruppate potrebbero aumentare la latenza della scalabilità automatica, perché GKE deve eseguire più simulazioni per determinare la configurazione ottimale dei nodi. La probabilità che tu noti un aumento della latenza dipende dall'ampiezza della selezione dell'hardware nella regola, come segue:

    • Le regole con un ambito ampio, come la proprietà machineFamily, hanno maggiori probabilità di contribuire a un leggero aumento della latenza della scalabilità automatica. Tuttavia, è più probabile che GKE trovi hardware disponibile che soddisfi i requisiti di queste regole.
    • Le regole con un ambito ristretto, come la proprietà machineType, hanno meno probabilità di contribuire a un aumento della latenza. Tuttavia, è più probabile che GKE non riesca a trovare hardware disponibile che soddisfi i requisiti di queste regole.

Il seguente esempio mostra una ComputeClass che imposta i punteggi delle regole di priorità:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: priority-rule-score-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  # Highest priority score in the ComputeClass
  - machineFamily: e2
    spot: true
    priorityScore: 30
  # Grouped priority rules that have the same score.
  - machineFamily: n2
    spot: true
    priorityScore: 20
  - machineFamily: t2d
    spot: true
    priorityScore: 20
  # Lowest priority score in the ComputeClass.
  - machineFamily: n1
    spot: true
    priorityScore: 10
  whenUnsatisfiable: ScaleUpAnyway

Durante un evento di scale up per questa ComputeClass di esempio, GKE esegue le seguenti operazioni:

  1. GKE tenta di creare istanze E2.
  2. Se le istanze E2 non sono disponibili, GKE crea istanze N2 o T2D, a seconda del risultato del gestore della scalabilità automatica del cluster.
  3. Se le istanze N2 e T2D non sono disponibili, GKE tenta di creare istanze N1.
  4. Se le istanze N1 non sono disponibili, GKE torna alla serie di macchine predefinita per il cluster.

Proprietà del nodo di primo livello per le regole di priorità

Quando specifichi le regole di priorità che definiscono le proprietà dei nodi, devi selezionare un tipo di hardware di primo livello per i nodi. Le altre proprietà che puoi specificare per una regola dipendono dalla proprietà di primo livello della regola.

Puoi utilizzare una qualsiasi delle seguenti proprietà di primo livello per una regola:

  • machineFamily: una serie di macchine Compute Engine, ad esempio n4.
  • machineType: un tipo di macchina Compute Engine specifico, ad esempio n4-standard-32.
  • gpu: una configurazione GPU, che potrebbe includere un tipo di GPU, un numero specifico di GPU e la configurazione dei driver.
  • tpu: una configurazione di Cloud TPU, che potrebbe includere una versione, una topologia e un numero di chip TPU.

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

Ogni generazione di serie di macchine Compute Engine supporta tipi di dischi specifici. Ad esempio, la serie di macchine N4 supporta i tipi di dischi Hyperdisk ML, ma la serie di macchine N2 no. In ComputeClasses che si estendono su più generazioni, i workload stateful che richiedono un tipo di disco specifico potrebbero non essere in grado di accedere ai dati permanenti se il tipo di macchina non supporta quel tipo di disco. A seconda di come crei e utilizzi i dischi nei tuoi workload, utilizza uno dei seguenti metodi per ridurre il rischio di dati persistenti inaccessibili:

  • Provisioning dinamico dei volumi: in GKE versione 1.35.3-gke.1290000 e successive, utilizza una StorageClass che configura la selezione automatica del tipo di disco. GKE crea un tipo di disco compatibile con il tipo di macchina del nodo che esegue il tuo workload. Nelle versioni precedenti di GKE, verifica che tutte le serie di macchine in ComputeClass supportino il tipo di disco di cui viene eseguito il provisioning da StorageClasses.

  • Dischi permanenti preesistenti: verifica che tutte le serie di macchine in ComputeClass supportino i tipi di dischi permanenti preesistenti.

Per ulteriori informazioni sui tipi di dischi supportati per ogni serie di macchine, consulta la tabella di confronto delle serie di macchine.

configurazioni machineFamily

Il campo machineFamily accetta qualsiasi serie di macchine Compute Engine supportata da GKE, ad esempio n2 o c3. Se non specificato, il valore predefinito è e2. Quando utilizzi il campo machineFamily, GKE esegue il provisioning dei nodi di quella serie con un tipo di macchina sufficientemente grande per eseguire i tuoi pod. L'algoritmo del gestore della scalabilità automatica determina le dimensioni più appropriate in base alle richieste di risorse aggregate di tutti i pod in attesa. Per un maggiore controllo sulle dimensioni esatte della macchina, utilizza il campo machineType.

La richiesta di una famiglia di macchine più ampia non esegue il provisioning dei tipi di macchine bare metal. Ad esempio, la richiesta di c3 o c4a non esegue il provisioning di tipi di macchine come c3-standard-192-metal o c4a-standard-72-metal rispettivamente. Poiché i tipi di nodi bare metal richiedono la richiesta di un tipo di macchina esatto, non puoi utilizzare neanche la classe di computing Autopilot Performance predefinita. Devi invece creare una ComputeClass personalizzata e specificare il tipo di macchina esatto nel campo machineType. L'utilizzo dei tipi di macchine bare metal c3 o c4a con ComputeClasses, la creazione automatica pool di nodi o la modalità Autopilot richiede GKE versione 1.35.3-gke.1389000 o successiva.

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

  • spot: VM spot. Il valore predefinito è false.
  • minCores: vCPU minime per nodo. Il valore predefinito è 0. Questo campo è utile per impedire la creazione di nodi troppo piccoli per le tue esigenze.
  • minMemoryGb: la memoria minima per nodo. Il valore predefinito è 0.
  • storage.bootDiskType: il tipo di disco di avvio. Sui cluster Autopilot è supportato solo il tipo pd-balanced di bootDiskType. Richiede GKE 1.34.1-gke.1431000 o versioni successive.
  • storage.bootDiskSize: le dimensioni in GB del disco di avvio del nodo. Richiede GKE 1.34.1-gke.1431000 o versioni successive.
  • storage.bootDiskKMSKey: il percorso della chiave di Cloud Key Management Service da utilizzare per la crittografia del disco di avvio.
  • storage.secondaryBootDisks: Persistent Disk utilizzati per precaricare i nodi GKE con dati, ad esempio un modello di machine learning (ML) o un'immagine container. Richiede GKE versione 1.31.2-gke.1105000 o successive. Per configurare un disco di avvio secondario da utilizzare per il cluster, consulta Configura 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 delle immagini container. Il valore deve essere uguale a CONTAINER_IMAGE_CACHE o MODE_UNSPECIFIED. Se questo valore non viene specificato, il valore predefinito è MODE_UNSPECIFIED.
  • placement: i dettagli del posizionamento della macchina:
  • enableNestedVirtualization: indica se attivare la virtualizzazione nidificata sui nodi. Il valore predefinito è false.

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

priorities:
- machineFamily: n4
  spot: true
  minCores: 16
  minMemoryGb: 64
  storage:
    bootDiskType: hyperdisk-balanced
    bootDiskSize: 100
    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, ad esempio n4-standard-32, o una stringa di tipo di macchina personalizzata, ad esempio n4-custom-8-20480. L'utilizzo di tipi di macchine personalizzate richiede GKE versione 1.33.2-gke.1111000 o successive. Puoi specificare i tipi di macchina di qualsiasi serie di macchine supportata da GKE.

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

  • spot: utilizza le VM spot. Il valore predefinito è false.
  • storage: configura lo spazio di archiviazione dei nodi.
    • storage.bootDiskType: il tipo di disco di avvio. In 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: le dimensioni in GB del disco di avvio del nodo.
    • storage.localSSDCount: il numero di SSD locali da collegare al nodo. Se specificato, deve essere almeno 1.
  • enableNestedVirtualization: indica se abilitare la virtualizzazione nidificata sui nodi. Il valore predefinito è false.

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

priorities:
- machineType: n4-standard-32
  spot: true
  storage:
    bootDiskType: hyperdisk-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 il campo driverVersion (facoltativo) della GPU nel campo gpu di una regola di priorità. Sono supportati i seguenti campi:

  • gpu.type: un tipo di GPU, ad esempio nvidia-l4. Per i dettagli, vedi Scegliere il supporto GPU utilizzando Autopilot o Standard.
  • gpu.count: il numero di GPU da collegare. Per le quantità supportate per tipo di GPU, consulta Quantità di GPU supportate.
  • gpu.driverVersion: la versione del driver NVIDIA da installare. Deve essere default o latest. Richiede GKE versione 1.31.1-gke.1858000 o successive.
  • acceleratorNetworkProfile: il profilo di rete dell'acceleratore per la GPU, ad esempio auto. Richiede GKE 1.35.2-gke.1842000 o versioni successive.

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 campi spec.priorities insieme al campo tpu nella regola di priorità, ad esempio:

  • spot: utilizza le VM spot. Il valore predefinito è false.
  • storage: configura lo spazio di archiviazione dei nodi.
    • storage.bootDiskType: il tipo di disco di avvio.
    • storage.bootDiskKMSKey: il percorso della chiave Cloud KMS da utilizzare per la crittografia del disco di avvio.
    • storage.bootDiskSize: le dimensioni in GB del disco di avvio del nodo.
  • reservations: utilizza una prenotazione Compute Engine. Per maggiori dettagli, consulta la sezione Utilizza le prenotazioni di Compute Engine.
  • location:
    • zones: un elenco di zone Google Cloud in cui GKE può eseguire il provisioning dei nodi. Se non specificato, GKE esegue il provisioning dei nodi nelle zone configurate nelle impostazioni di provisioning automatico dei nodi del cluster. Se non sono configurate zone per il provisioning automatico dei nodi, GKE esegue il provisioning dei nodi in una delle zone standard utilizzate dal control plane.

      (Facoltativo) Utilizza una AI zone, ad esempio us-central1-ai1a. Le zone AI sono località specializzate ottimizzate per i workload AI/ML all'interno delle regioni Google Cloud .

    • zoneTypes: un elenco di tipi di zone che specifica un insieme di zone Google Cloud in cui GKE può eseguire il provisioning dei nodi. I valori supportati sono CLUSTER_DEFAULT (predefinito), STANDARD e AI. Per saperne di più, consulta Utilizzo della priorità dei tipi di zone di localizzazione.

L'esempio seguente 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 fallback:

  1. GKE tenta di eseguire il provisioning di una sezione TPU v5p multi-host a 16 nodi utilizzando una prenotazione Compute Engine condivisa denominata tpu-reservation del 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 nella sezione Definisci il comportamento di scalabilità quando non vengono applicate regole di priorità.

Dopo aver eseguito il deployment di una classe ComputeClass TPU personalizzata nel cluster, selezionala nel workload:

Inoltre, per i workload TPU puoi:

Targeting delle zone AI

Puoi anche utilizzare una classe di computing per specificare le zone AI per i tuoi pod. Le zone AI sono località specializzate all'interno delle regioni Google Cloud ottimizzate per i workload AI/ML. La seguente classe di computing imposta un elenco di zone con priorità che include le zone AI:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: accelerator-ai-preferred
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
    # --- Priority 1: TPU in a specific AI zone (On-Demand) ---
    - tpu:
        type: tpu-v5p-slice
        count: 4
        topology: 4x4x4
      location:
        zones:
          - "us-central1-ai1a" # Specify your target AI zone
      # machineFamily: a3 # Optional

    # --- Priority 2: TPU in any AI zone (On-Demand)  ---
    - tpu:
        type: tpu-v5p-slice
        count: 4
        topology: 4x4x4
      location:
        zoneTypes:
          - "AI" # All AI zones in the cluster's region

    # --- Priority 3: GPU in a specific Standard zone (On-Demand) ---
    - gpu:
        type: nvidia-tesla-a100
        count: 1
      location:
        zones:
          - "us-central1-a" # Fallback to a standard zone
          - "us-central1-b"
  whenUnsatisfiable: DoNotScaleUp

Questa ComputeClass configura GKE per il provisioning di nodi con TPU v5p o GPU A100 per il workload. I nodi hanno le seguenti preferenze:

  • Priorità 1:tentativo di provisioning della TPU nella zona AI us-central1-ai1a.
  • Priorità 2: se la TPU non è disponibile nella zona AI specifica, tenta di eseguirne il provisioning in qualsiasi zona AI della regione del cluster.
  • Priorità 3: se la TPU non è disponibile nelle zone AI, tenta di eseguire il provisioning della GPU nelle zone standard us-central1-a o us-central1-b.
  • Se le GPU A100 non sono disponibili in nessuna delle zone specificate, GKE non farà lo scale up del pool di nodi.

Configurazione di rete DRANET

Richiede GKE 1.35.2-gke.1842000 o versioni successive

Per utilizzare GKE managed DRANET per richiedere e allocare interfacce di rete per i pod, devi abilitare la funzionalità in ComputeClass. Devi:

  • Attiva il driver di networking DRANET impostando nodePoolConfig.dra.networking.enabled su true.
  • Imposta acceleratorNetworkProfile su auto nell'elenco priorities.

Per saperne di più su come utilizzare DRANET, consulta Allocare risorse di rete utilizzando DRANET gestito da GKE.

In che modo GKE crea i nodi utilizzando le regole di priorità

Quando esegui il deployment di un workload che richiede una ComputeClass ed è necessario un nuovo nodo, GKE elabora l'elenco di regole nel campo priorities della specifica ComputeClass in ordine di visualizzazione o, se il campo priorityScore è impostato, dal punteggio più alto a quello più basso.

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 classe ComputeClass con queste regole di priorità, GKE associa i nodi come segue:

  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 nella regione non sono disponibili VM spot N4 con almeno 64 vCPU, GKE esegue il provisioning di nuovi nodi che utilizzano VM spot N4 in grado di adattarsi ai 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 nella sezione Definisci il comportamento di scalabilità quando non vengono applicate regole di priorità.

Valori predefiniti per le regole di priorità

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 GKE 1.32.1-gke.1729000 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 la pianificazione dei pod ComputeClass avvenga 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, devi configurarli per associarli a classi di calcolo specifiche. GKE pianifica i pod che richiedono una ComputeClass specifica solo sui nodi nei node pool che associ a quella ComputeClass. Questo requisito non si applica a una ComputeClass che configuri come predefinita a livello di cluster.

La modalità GKE Autopilot e i pool di nodi creati automaticamente in modalità GKE Standard eseguono questa configurazione per te.

Per associare un pool di nodi creato manualmente a una ComputeClass, aggiungi etichette dei nodi e contaminazioni dei nodi al pool di nodi durante la creazione o l'aggiornamento specificando il flag --node-labels e il flag --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 un pool di nodi esistente e lo associano alla classe 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 del cluster a una classe ComputeClass personalizzata. I pod che GKE pianifica su questi node pool creati manualmente attivano la creazione di nodi solo all'interno di questi node pool durante gli eventi di scalabilità automatica.

Creazione automatica dei pool di nodi e ComputeClasses

Puoi utilizzare la creazione automatica dei pool di nodi con una ComputeClass personalizzata per consentire a GKE di creare ed eliminare automaticamente i node pool in base alle tue regole di priorità.

Per consentire a GKE di creare automaticamente node pool per una ComputeClass, devi procedere nel seguente modo:

  1. Aggiungi il campo nodePoolAutoCreation con il valore enabled: true alla specifica ComputeClass.
  2. Se il tuo cluster esegue una versione precedente alla versione GKE 1.33.3-gke.1136000, devi anche abilitare il provisioning automatico dei nodi a livello di cluster.

GKE può quindi creare nuovi node pool per i pod che utilizzano la tua ComputeClass. GKE decide se fare lo scale up di un pool di nodi esistente o creare un nuovo pool di nodi in base a fattori come le dimensioni dei cluster e i requisiti dei pod. I pod con classi di computing che non configurano la creazione automatica dei pool di nodi continuano a fare lo scale up solo dei pool di nodi esistenti.

Puoi utilizzare ComputeClasses che abilitano la creazione automatica dei pool di nodi insieme a ComputeClasses che interagiscono con i node pool creati manualmente nello stesso cluster.

Considera le seguenti interazioni con la creazione automatica del pool di 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 classe ComputeClass predefinita a livello di cluster ha un valore 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 presente nelle priorità predefinite della classe a livello di cluster non attivano la creazione di nodi se ComputeClass ha un valore di DoNotScaleUp nel campo whenUnsatisfiable.

  • Puoi configurare la creazione automatica pool di nodi per le ComputeClass che utilizzano il campo nodepools per fare riferimento ai node pool esistenti. GKE elabora le priorità in ordine e tenta di fare lo scale up dei pool di nodi esistenti per posizionare i pod.

Considera il seguente esempio per un cluster con pool di nodi creati manualmente e con creazione automatica dei pool di 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 pool di nodi.
  3. Se GKE non riesce a creare nodi N4, tenta di fare lo scale up dei node pool C4 esistenti o di creare nuovi node pool C4.

Scegli come target pool di nodi specifici in una definizione ComputeClass

Il campo priorities.nodepools consente di specificare un elenco di node pool creati manualmente su cui GKE tenta di pianificare i pod in nessun ordine specifico nei cluster GKE Standard che utilizzano il gestore della scalabilità automatica dei cluster. Questo campo supporta solo un elenco di pool di nodi. Non puoi specificare proprietà macchina aggiuntive come la serie di macchine nella stessa regola di priorità. Quando esegui il deployment di un workload che richiede una classe 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 dei nodi 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 node pool 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 posizionare 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 node pool, 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 ci sono nodi che possono soddisfare una delle regole di priorità. Il campo whenUnsatisfiable nella specifica supporta i valori seguenti.

  • ScaleUpAnyway: crea un nuovo nodo che utilizza 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 la creazione automatica di pool di nodi, GKE tenta di scalare orizzontalmente qualsiasipool di nodil creato manualmente che definisce un'etichetta e un taint corrispondenti a una determinata ComputeClass.
    • Nei cluster Standard che utilizzano la creazione automatica di pool di nodi, GKE potrebbe creare un nuovo pool di nodi che utilizza la serie di macchine E2 predefinita 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.

Richiedi 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 una policy di posizionamento o una policy di workload personalizzata. Per ulteriori informazioni, consulta Confronto tra policy di posizionamento compatto e 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 suo nome in un campo policyName. La policy deve essere una policy delle risorse di Compute Engine già esistente 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 delle risorse esistente denominata my-placement-policy.

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

Per impostazione predefinita, GKE rimuove i nodi sottoutilizzati dai workload in esecuzione, consolidando questi workload su altri nodi con capacità disponibile. Per tutte le classi di computing, questo è il comportamento predefinito perché tutti i cluster che utilizzano le classi di computing 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 workload su un altro nodo ed elimina il nodo svuotato.

La tempistica 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 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%.

Migrazione attiva

La migrazione attiva è una funzionalità di scalabilità automatica facoltativa in ComputeClasses che sostituisce automaticamente i nodi esistenti con nuovi nodi. Sono supportati i seguenti tipi di migrazione attiva:

  • optimizeRulePriority: GKE sostituisce i nodi che utilizzano una configurazione con priorità inferiore con nodi che utilizzano una configurazione con priorità superiore. Questa opzione ti consente di assicurarti che i tuoi pod vengano eseguiti sulla configurazione dei nodi che preferisci, anche se GKE ha dovuto inizialmente eseguire i pod su una configurazione dei nodi meno preferita.
  • ensureAllDaemonSetPodsRunning: GKE sostituisce i nodi con pod DaemonSet non pianificabili con nodi più grandi in grado di eseguire tutti i pod DaemonSet richiesti. Questa opzione ti aiuta a garantire che tutti i tuoi DaemonSet vengano eseguiti sui tuoi nodi.

Durante una migrazione attiva, GKE esegue le seguenti operazioni:

  1. GKE crea un nuovo nodo con una configurazione che soddisfa i requisiti del tipo di migrazione attivo.
  2. GKE isola il nodo esistente in modo che i nuovi pod non vengano eseguiti su quel nodo.

  3. GKE svuota il nodo esistente, rimuovendo i pod dal nodo. I seguenti fattori influiscono sulla rapidità con cui viene svuotato il nodo:

    I controller Kubernetes, come deployment o job, creano pod per sostituire i pod eliminati. GKE pianifica questi nuovi pod sul nuovo nodo.

  4. Dopo aver svuotato il nodo esistente, GKE lo elimina.

La migrazione attiva non influisce su pod e nodi nei seguenti scenari:

  • La migrazione attiva non espelle i pod con l'annotazione cluster-autoscaler.kubernetes.io/safe-to-evict: "false".
  • La migrazione attiva non espelle i pod se l'espulsione violerebbe un PodDisruptionBudget.
  • La migrazione attiva non sostituisce i nodi che non possono essere rimossi. Ad esempio, la migrazione attiva non sostituisce un nodo se questa operazione viola l'impostazione del pool di nodi --min-nodes.

Prima di attivare la migrazione attiva per una ComputeClass, considera i seguenti potenziali effetti:

  • La migrazione attiva non esegue la migrazione dei dati archiviati in archiviazione permanente, come i Persistent Disk di 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.
  • Nei cluster Standard, se utilizzi la creazione automatica del pool di nodi, la migrazione attiva potrebbe attivare la creazione di nuovi pool di nodi se quelli esistenti non soddisfano i criteri definiti in ComputeClass.
  • I carichi di lavoro che utilizzano volumi permanenti con risorse di zona come Hyperdisk potrebbero non funzionare bene con la migrazione attiva. Le limitazioni di zona e le limitazioni del tipo di macchina di alcuni prodotti Hyperdisk possono ridurre l'efficacia della migrazione attiva. Inoltre, alcuni workload stateful potrebbero non tollerare l'interruzione causata dalla migrazione attiva.
  • Se aggiorni una classe ComputeClass esistente per attivare la migrazione attiva, GKE esegue la migrazione dei pod esistenti ai nuovi nodi quando le risorse di computing diventano disponibili.

Migrazione attiva a nodi con priorità più alta

Il tipo di migrazione attiva optimizeRulePriority consente a GKE di sostituire i nodi esistenti che utilizzano una configurazione con priorità inferiore con nodi che utilizzano una configurazione con priorità più alta.

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 fossero stati disponibili durante 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à, si verificano i seguenti passaggi:

  1. GKE crea un nuovo nodo N4.
  2. GKE isola e svuota il nodo C4 esistente. I pod vengono espulsi, rispettando eventuali configurazioni di PodDisruptionBudget e di terminazione controllata.
  3. I controller Kubernetes creano pod per sostituire quelli eliminati. Questi nuovi pod vengono eseguiti sul nodo N4.
  4. Dopo aver svuotato il nodo C4, GKE lo elimina.

Analogamente, se utilizzi il campo priorityScore per impostare punteggi espliciti per le regole di priorità, GKE sostituisce i nodi con un punteggio inferiore con nodi con un punteggio superiore.

Migrazione attiva per eseguire i pod DaemonSet non pianificabili

Il tipo di migrazione attiva ensureAllDaemonSetPodsRunning consente a GKE di sostituire automaticamente i nodi esistenti che hanno pod DaemonSet non pianificabili con nodi più grandi che possono eseguire questi pod DaemonSet.

Ad esempio, la seguente specifica ComputeClass configura la famiglia di macchine N4:

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

Considera uno scenario in cui hai creato un deployment a singolo pod che utilizzava questa ComputeClass e richiedeva due vCPU. Per eseguire questo pod, GKE ha creato un nodo n4-standard-2. In un secondo momento, crei un DaemonSet che richiede anche due vCPU. Il pod DaemonSet non può essere eseguito sul nodo n4-standard-2. In questo scenario, GKE esegue le seguenti operazioni:

  1. GKE crea un nodo che utilizza un tipo di macchina N4 più grande, ad esempio n4-standard-4, che può eseguire il pod e il pod DaemonSet. Il pod DaemonSet in attesa viene pianificato su questo nuovo nodo.
  2. GKE isola e svuota il nodo n4-standard-2.
  3. Quando il pod viene rimosso, il deployment crea un pod sostitutivo. GKE pianifica questo pod sul nodo n4-standard-4, insieme al pod DaemonSet.
  4. Dopo aver svuotato il nodo n4-standard-2, GKE lo elimina.

Consumare le prenotazioni di Compute Engine

Disponibile in GKE versione 1.31.1-gke.2105000 e successive

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

Per utilizzare le prenotazioni Compute Engine utilizzando una ComputeClass personalizzata, puoi utilizzare i seguenti metodi:

  • Creazione automatica dei node pool: GKE crea automaticamente nuovi node pool per utilizzare le prenotazioni specificate. Per saperne di più, consulta Creazione automatica di pool di nodi e ComputeClass.
  • Node pool creati manualmente: nei cluster in modalità Standard, puoi indirizzare i workload ai node pool creati manualmente specificando il campo spec.priorities.nodepools in ComputeClass.

A partire dalla versione 1.36.0-gke.3204000 di GKE, puoi configurare i tuoi workload in modo che utilizzino qualsiasi prenotazione corrispondente senza tornare alla capacità on demand utilizzando l'impostazione di affinità AnyThenFail.

Utilizza le prenotazioni nei node pool creati manualmente

Per utilizzare le prenotazioni nei node pool creati manualmente nei cluster Standard utilizzando le classi di calcolo, segui questi passaggi:

  1. Associa le prenotazioni ai node pool seguendo i passaggi descritti in Utilizzo di istanze dedicate in GKE Standard.

  2. Crea una classe ComputeClass che utilizzi la regola di priorità nodepools per selezionare i node pool creati manualmente.

Ad esempio, considera uno scenario in cui hai due pool di nodi, ciascuno dei quali è collegato a una prenotazione di capacità separata. Preferisci che i pod utilizzino la capacità riservata nel pool di nodi reservation-pool-1 anziché nel pool di nodi reservation-pool-2. ComputeClass che implementa queste preferenze è simile al seguente esempio:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: manual-pool-reservations
spec:
  priorities:
  - nodepools: ['reservation-pool-1']
  - nodepools: ['reservation-pool-2']

In questo esempio, GKE tenta di inserire i pod in reservation-pool-1 per primi, perché questa regola di priorità viene visualizzata per prima nel campo priorities.

Crea automaticamente i node pool per utilizzare le prenotazioni

Se utilizzi la creazione automatica dei pool di nodi, puoi richiedere a GKE di utilizzare le prenotazioni di capacità per creare node pool per regole di priorità specifiche. Per utilizzare le prenotazioni nei node pool creati automaticamente, devi soddisfare i seguenti requisiti:

  • La classe ComputeClass deve abilitare la creazione automatica dei node pool.
  • Le prenotazioni non TPU possono essere utilizzate solo se è definito machineType o machineFamily.
  • Le ComputeClass che configurano gli SSD locali devono utilizzare la regola di priorità machineType, non machineFamily. Per maggiori dettagli, consulta la sezione Tipo di regola machineType.
  • ComputeClasses che specificano prenotazioni per un machineType con SSD locali collegati devono includere esplicitamente un campo localSSDCount:.

Considera la seguente specifica 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 istanze con priorità non sono disponibili, GKE utilizza le 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 la classe di computing accelerator-reservations, 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 utilizza le 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 alle prenotazioni 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:

    • Specifica il nome della prenotazione nel campo reservations.specific.name.
    • Assicurati che il valore del campo reservations.affinity sia Specific.

  • Prenotazioni condivise specifiche: configura i seguenti campi:

    • Specifica il nome della prenotazione nel campo reservations.specific.name.
    • Specifica l'ID del progetto proprietario della prenotazione nel campo reservations.specific.project.
    • Assicurati che il valore del campo reservations.affinity sia Specific.

  • Qualsiasi prenotazione corrispondente con fallback: configura i seguenti campi:

    • Assicurati che il valore del campo reservations.affinity sia AnyBestEffort.
    • Non impostare un nome o un progetto per la prenotazione.

  • Qualsiasi prenotazione corrispondente senza fallback: configura i seguenti campi:

    • Assicurati che il valore del campo reservations.affinity sia AnyThenFail.
    • Non impostare un nome o un progetto per la prenotazione.
    • Facoltativo. Per applicare rigorosamente l'errore se le prenotazioni corrispondenti sono esaurite, configura l'impostazione whenUnsatisfiable: DoNotScaleUp a livello di spec di ComputeClass.

Le prenotazioni di TPU richiedono l'affinità specifica. Le impostazioni reservations.affinity: AnyBestEffort e reservations.affinity: AnyThenFail non sono supportate.

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

  • Prenotazioni specifiche: GKE prova la regola di priorità successiva in ComputeClass.
  • Qualsiasi prenotazione corrispondente con fallback (AnyBestEffort): GKE tenta di eseguire il provisioning di un nodo on demand che soddisfi i requisiti di questa regola di priorità. Se GKE non può eseguire il provisioning di un nodo on demand, GKE prova la regola di priorità successiva nella classe ComputeClass.
  • Eventuali prenotazioni corrispondenti senza fallback (AnyThenFail): GKE salta il provisioning di un nodo on demand e prova la regola di priorità successiva in ComputeClass. Se non si applicano altre regole, l'operazione di scalabilità non riesce a seconda del valore dell'impostazione whenUnsatisfiable.

Se GKE non riesce a soddisfare i requisiti di nessuna delle regole di priorità per la classe ComputeClass, si verifica il comportamento quando non vengono applicate regole.

Consuma 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 con crittografia 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 target.

A partire dalla versione 1.33.1-gke.1788000 di GKE, puoi scegliere come target un blocco secondario di prenotazione specifico all'interno di un blocco di prenotazione. 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 alle prenotazioni specifiche in un progetto singolo o condiviso.

Conteggi minimi dei nodi

Disponibile in GKE 1.36.3-gke.1253000 e versioni successive.

Puoi specificare un numero minimo di nodi che GKE deve mantenere per un'intera ComputeClass o per regole di priorità specifiche utilizzando il campo minimumCapacity.targetNodeCount. GKE mantiene almeno il numero di nodi specificato, anche se la capacità è inattiva. La specifica di una capacità minima è ideale per i workload che richiedono una quantità di base di capacità di calcolo, come l'addestramento di AI/ML su larga scala o i workload di gestione a bassa latenza. GKE continua a scalare automaticamente i nodi al di sopra del minimo quando i tuoi workload richiedono più capacità.

Quando specifichi una capacità minima per una ComputeClass o una regola di priorità, considera il seguente comportamento:

  • Se la capacità è per l'intera ComputeClass, GKE mantiene almeno quel numero di nodi in tutte le regole di priorità della ComputeClass. Se la capacità è per una regola di priorità specifica, GKE mantiene almeno quel numero di nodi per quella regola di priorità.
  • Se il numero di nodi è inferiore al numero minimo specificato, GKE crea automaticamente nuovi nodi per mantenere la capacità minima, anche se questi nodi aggiuntivi non eseguono nessuno dei tuoi pod.
  • GKE non fa fare lo scale down dei nodi che compongono la capacità minima, anche se questi nodi sono vuoti.
  • La capacità specificata è un valore minimo. Durante gli eventi di scale up, GKE può superare il numero minimo di nodi per eseguire i pod in attesa.
  • Se abiliti la migrazione attiva ai nodi con priorità più alta, GKE può sostituire i nodi per la capacità minima con nodi di una regola con priorità più alta. Tuttavia, GKE non sostituisce un nodo se la sostituzione porta una regola di priorità al di sotto della sua capacità minima.
  • La disponibilità o le quote delle risorse potrebbero impedire a GKE di creare nodi per il requisito di capacità minima.
  • Se GKE non riesce a creare un numero di nodi sufficiente per la capacità minima di una regola di priorità, non esegue il fallback ad altre regole di priorità. GKE crea invece i nodi mancanti per questa regola di priorità quando la capacità diventa disponibile.
  • I nodi potrebbero comunque essere eliminati e sostituiti per mantenere l'integrità del cluster (ad esempio, per correggere un nodo non integro o per eseguire il preempt di una VM spot). GKE crea automaticamente nuovi nodi per mantenere la capacità minima.

A seconda che configuri una capacità minima per un'intera ComputeClass o per regole di priorità specifiche, si applicano i seguenti requisiti:

  • Capacità minima per ComputeClass: se specifichi il campo minimumCapacity.targetNodeCount per l'intera ComputeClass, tutte le regole di priorità devono richiedere direttamente o indirettamente un tipo di macchina specifico. Ogni regola di priorità deve utilizzare almeno una delle seguenti configurazioni:

    • machineType
    • gpu
    • tpu
    • Una prenotazione di capacità specifica

    GKE rifiuta le ComputeClass che utilizzano configurazioni flessibili in una regola di priorità, ad esempio il campo machineFamily, e che specificano anche una capacità minima per l'intera ComputeClass.

  • Capacità minima per una regola di priorità: se specifichi il campo minimumCapacity.targetNodeCount per una regola di priorità specifica, questa regola deve richiedere direttamente o indirettamente un tipo di macchina specifico utilizzando almeno una delle seguenti configurazioni:

    • machineType
    • gpu
    • tpu
    • Una prenotazione di capacità specifica

I seguenti esempi mostrano la configurazione della capacità minima per una classe ComputeClass e per una regola di priorità:

  • ComputeClass:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: gpu-class-min-nodes
spec:
  nodePoolAutoCreation:
    enabled: true
  # Define a global minimum capacity of 5 nodes for this ComputeClass
  minimumCapacity:
    targetNodeCount: 5
  priorities:
  - gpu:
      type: "nvidia-tesla-a100"
      count: 1
    machineType: "a2-highgpu-1g"
  - gpu:
      type: "nvidia-l4"
      count: 1
    machineType: "g2-standard-8"

  • Regola di priorità:

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: tiered-compute-class
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - machineType: "n2-standard-16"
    # Maintain at least three nodes of this specific configuration
    minimumCapacity:
      targetNodeCount: 3
  - machineType: "e2-standard-4"

Capacità minima sia per una classe ComputeClass sia per le relative regole di priorità

Se specifichi una capacità minima per una ComputeClass e per alcune delle sue regole di priorità, i minimi delle regole di priorità vengono conteggiati ai fini del minimo della ComputeClass. Si applica dunque il seguente comportamento:

  • Se i minimi delle regole di priorità sommati raggiungono almeno il minimo di ComputeClass, i nodi per le regole di priorità soddisfano anche il minimo di ComputeClass. GKE non crea nodi aggiuntivi per il valore minimo di ComputeClass, nemmeno nelle regole con priorità più alta che non specificano una capacità minima.
  • Il valore minimo di ComputeClass non limita i valori minimi delle regole di priorità. GKE crea tutti i nodi per ogni minimo della regola di priorità, anche se il totale supera il minimo di ComputeClass.
  • Se la somma dei minimi delle regole di priorità è inferiore al minimo della classe di calcolo, GKE crea i nodi rimanenti utilizzando le regole di priorità in ordine. Se necessario, GKE torna alle regole di priorità inferiore per i nodi rimanenti.

Ad esempio, considera la seguente ComputeClass, che specifica una capacità minima per la ComputeClass e per la seconda regola di priorità:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: combined-min-nodes
spec:
  nodePoolAutoCreation:
    enabled: true
  minimumCapacity:
    targetNodeCount: 5
  priorities:
  - machineType: "n2-standard-16"
  - machineType: "e2-standard-16"
    minimumCapacity:
      targetNodeCount: 3

Per questa ComputeClass, GKE crea tre nodi e2-standard-16 per la regola di priorità secondaria. Questi nodi vengono conteggiati ai fini del numero minimo di cinque nodi di ComputeClass. Per i due nodi rimanenti, GKE tenta di creare prima i nodi n2-standard-16. Se i nodi n2-standard-16 non sono disponibili, GKE utilizza i nodi e2-standard-16.

Se attivi la migrazione attiva ai nodi con priorità più alta, GKE può sostituire in un secondo momento fino a due nodi e2-standard-16 con nodi n2-standard-16. Tuttavia, GKE mantiene almeno tre nodi e2-standard-16 per la capacità minima della seconda regola di priorità.

Se invece imposti il campo targetNodeCount nella regola con priorità secondaria su 6, GKE crea sei nodi e2-standard-16. Questi sei nodi soddisfano il minimo di cinque nodi di ComputeClass, quindi GKE non crea nodi n2-standard-16 per la capacità minima.

Personalizza la configurazione di sistema del nodo

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 tutti i campi di configurazione del sistema dei nodi omessi nelle regole di priorità aggiungendo il campo nodeSystemConfig al campo priorityDefaults in ComputeClass.

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

Per ulteriori informazioni, consulta le seguenti risorse:

Specifica le etichette e le incompatibilità dei nodi

Nella specifica ComputeClass, i campi nodeLabels e taints ti consentono di definire configurazioni che corrispondono ai pool di nodi esistenti e regolano la creazione di nuovi pool. Queste configurazioni possono essere applicate a livello globale all'interno del campo nodePoolConfig per l'intera ComputeClass o limitate a una priorità specifica utilizzando il campo priority; tuttavia, devi assicurarti che le etichette e i taint definiti a livello di priorità non si sovrappongano a quelli impostati a livello globale.

Queste funzionalità sono disponibili nei seguenti paesi:

  • Etichette dei nodi di priorità in GKE versione 1.33.2-gke.1111000 e successive.
  • Taint di priorità in GKE versione 1.33.4-gke.1350000 e successive.
  • Etichette e taint dei nodi globali in GKE versione 1.34.1-gke.3084002 e successive.

Oltre alle etichette personalizzate, GKE assegna automaticamente l'etichetta di sistema cloud.google.com/compute-class a tutti i nodi di cui è stato eseguito il provisioning o associati a una ComputeClass. Puoi filtrare ed elencare i nodi per ComputeClass:

kubectl get nodes -l cloud.google.com/compute-class=COMPUTECLASS_NAME

Per saperne di più, consulta CustomResourceDefinition ComputeClass.

Configura la taint dell'architettura Arm predefinita

Per impostazione predefinita, GKE aggiunge il taint kubernetes.io/arch=arm64:NoSchedule a tutti i nodi Arm, inclusi i nodi creati per ComputeClass personalizzate. GKE pianifica solo i workload che hanno una tolleranza per questa taint sui nodi Arm, il che contribuisce a impedire l'esecuzione di workload x86 su un'architettura incompatibile. Se i tuoi workload sono compatibili sia con x86 che con Arm, puoi disabilitare questa contaminazione predefinita. Qualsiasi workload che seleziona ComputeClass può essere eseguito sui nodi Arm, anche se questi workload non hanno la tolleranza per l'architettura Arm.

Puoi aggiornare il comportamento di taint predefinito nei node pool Standard e con i nodi creati per ComputeClass personalizzate. Per saperne di più sulla configurazione del comportamento per i node pool Standard, consulta Configura il taint predefinito dell'architettura Arm.

Per modificare il comportamento predefinito e consentire a GKE di pianificare i workload che non hanno una tolleranza corrispondente sui nodi Arm creati per una ComputeClass personalizzata, configura la ComputeClass come mostrato in questo esempio:

taintConfig:
  architectureTaintBehavior: NONE

Questo campo richiede un cluster che esegue GKE versione 1.36.2-gke.1498000 o successive.

ComputeClasses 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 Applica ComputeClasses 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 TPU multi-host

Richiede GKE 1.31.2-gke.1518000 o versioni successive. Disponibile solo in TPU Trillium (v6e)

Puoi raggruppare il tuo deployment TPU multi-host per impostare un obiettivo del livello di servizio (SLO) per 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 la configurazione che si riflette in tutti i nodi all'interno dei node pool 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 ti 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 il service account Google Cloud utilizzato dai nodi all'interno dei node pool gestiti dalla classe 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 della TPU

A partire dalla versione 1.32.2-gke.1359000 di GKE, puoi definire l'obiettivo del livello di servizio (SLO) per i tuoi workload 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 valori seguenti:

  • HIGH_AVAILABILITY: utilizza questo valore per i workload incentrati sulla disponibilità, come l'inferenza, per limitare e semplificare le interruzioni.
  • HIGH_THROUGHPUT: utilizza questo valore per i job batch o di addestramento che richiedono che l'intera infrastruttura sottostante sia in esecuzione per la maggior parte del tempo per fare progressi. Questo valore può essere utilizzato solo se è specificato anche nodePoolGroup.

L'esempio seguente definisce una ComputeClass per una raccolta TPU multi-host ottimizzata per 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 ulteriori informazioni, consulta le seguenti risorse:

Configurazione della sandbox

Richiede GKE 1.36.2-gke.1368000 o versioni successive

Puoi isolare i carichi di lavoro dal kernel host dei nodi eseguendo i pod in sandbox utilizzando GKE Sandbox. In ComputeClasses, puoi attivare GKE Sandbox e selezionare un tipo di sandbox per i nodi utilizzando il campo nodePoolConfig.sandbox. Sono supportati i seguenti tipi di sandbox:

  • gvisor: richiede GKE 1.36.2-gke.1368000 o versioni successive.
  • microvm: richiede GKE 1.37.0-gke.4713000 o versioni successive e nodi che utilizzano la virtualizzazione nidificata.

Per saperne di più su funzionalità, limitazioni e requisiti di questi tipi di sandbox, consulta Informazioni su GKE Sandbox.

Per utilizzare una classe ComputeClass per attivare e richiedere sandbox, consulta Isola i workload utilizzando GKE Sandbox.

Configurazione dei metadati dell'istanza

Richiede GKE versione 1.36.2-gke.1498000 o successiva.

Il campo instanceMetadata in una specifica ComputeClass ti consente di aggiungere coppie chiave-valore di metadati personalizzati direttamente nelle istanze VM di Compute Engine di cui viene eseguito il provisioning per i tuoi pool di nodi da Cluster Autoscaler o dal provisioning automatico dei nodi. Questo equivale a specificare il flag --metadata quando crei i node pool manualmente con Google Cloud CLI.

La configurazione dei metadati delle istanze personalizzate utilizzando ComputeClasses è supportata solo sui cluster in modalità GKE Standard (spec.autopilot.enabled: false).

Puoi specificare instanceMetadata in due punti all'interno di una classe ComputeClass:

  • Configurazione globale (spec.nodePoolConfig.instanceMetadata): applica globalmente coppie chiave-valore dei metadati personalizzati a tutti i nuovi pool di nodi e VM creati da ComputeClass.
  • Override specifici per la priorità (spec.priorities[].instanceMetadata): applica coppie chiave/valore dei metadati personalizzati solo quando GKE esegue il provisioning dei nodi utilizzando quella priorità specifica nella gerarchia.

Se la stessa chiave dei metadati è definita sia in nodePoolConfig.instanceMetadata che in priorities[].instanceMetadata, il valore specificato in priorities[].instanceMetadata esegue l'override del valore globale.

Schema e regole di convalida

Quando definisci instanceMetadata, rispetta i seguenti vincoli di convalida:

  • Tipo: coppie chiave-valore strutturate come map (map[string]string).
  • Limiti di dimensioni:
    • La dimensione massima di un singolo valore dei metadati è 32 KB (32.768 byte).
    • La dimensione combinata massima di tutte le coppie chiave-valore dei metadati nell'intera risorsa ComputeClass non può superare 512 KB (524.288 byte).
  • Limiti e formattazione delle chiavi:
    • Puoi definire un massimo di 32 coppie chiave-valore dei metadati personalizzati per ComputeClass.
    • Le chiavi devono contenere meno di 128 caratteri e possono contenere solo caratteri alfanumerici, trattini (-) e trattini bassi (_).
  • Chiavi riservate: GKE e Compute Engine riservano chiavi dei metadati di sistema specifiche necessarie per gestire le operazioni del cluster (come kube-env, user-data, startup-script e cluster-name). Non puoi eseguire l'override o specificare chiavi dei metadati di sistema riservate.
  • Immutabilità sui node pool esistenti: la modifica di instanceMetadata su un ComputeClass esistente viene applicata solo quando GKE esegue il provisioning di nuovi node pool (quando nodePoolAutoCreation è abilitato). I node pool e le VM esistenti non vengono modificati retroattivamente.

L'esempio seguente mostra come configurare sia i metadati dell'istanza globale in tutti i pool di nodi sia un override dei metadati specifico per la priorità:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: metadata-example-class
spec:
  nodePoolAutoCreation:
    enabled: true
  nodePoolConfig:
    instanceMetadata:
      environment: "production"
      team: "backend-platform"
  priorities:
  - machineFamily: n4
    instanceMetadata:
      workload-tier: "high-performance"
  - machineFamily: e2
    instanceMetadata:
      workload-tier: "fallback-general"
      team: "shared-infra"

Configura i limiti di scalabilità automatica

Disponibile in GKE versione 1.36.2-gke.2064000 e successive.

Per impostazione predefinita, GKE esegue il provisioning di nuovi nodi per una ComputeClass fino ai limiti di scalabilità automatica complessivi del cluster. Per applicare limiti di risorse più rigidi per una ComputeClass specifica, ad esempio limitando il numero massimo di GPU, CPU o nodi totali che possono essere sottoposti a provisioning per la ComputeClass, puoi applicare una risorsa personalizzata CapacityQuota.

Per saperne di più, consulta Configura limiti di risorse granulari.

Configurazione di Shielded GKE Nodes

Richiede GKE 1.36.3-gke.1244000 o versioni successive

Per configurare le funzionalità di Shielded GKE Nodes, come l'avvio protetto e il monitoraggio dell'integrità, per i node pool creati automaticamente e gestiti da una ComputeClass, specifica il campo shieldedInstanceConfig nel blocco nodePoolAutoCreation (spec.nodePoolAutoCreation.shieldedInstanceConfig).

I valori predefiniti per shieldedInstanceConfig dipendono dalla modalità del cluster e dalla configurazione di ComputeClass:

  • Nei cluster in modalità Standard: quando shieldedInstanceConfig viene inizializzato durante la riconciliazione di nodePoolAutoCreation, il campo enableIntegrityMonitoring viene impostato su true e il campo enableSecureBoot viene impostato su false, a meno che non li configuri esplicitamente.
  • Nei cluster Autopilot (o quando spec.autopilot.enabled è true in una ComputeClass): i campi enableSecureBoot e enableIntegrityMonitoring sono impostati su true per impostazione predefinita e non possono essere disattivati.

L'esempio seguente mostra come configurare il campo shieldedInstanceConfig all'interno del blocco nodePoolAutoCreation per abilitare le funzionalità di Shielded GKE Nodes nei node pool creati automaticamente:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: shielded-ccc
spec:
  nodePoolAutoCreation:
    enabled: true
    shieldedInstanceConfig:
      enableSecureBoot: true
      enableIntegrityMonitoring: true

Richiedere ComputeClass nei workload

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

Ad esempio, il seguente manifest richiede la classe 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: registry.k8s.io/pause
        resources:
          requests:
            cpu: 1.5
            memory: "4Gi"

Selettori di 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
  • node.kubernetes.io/instance-type

In GKE versione 1.32.3-gke.1499000 e successive, puoi eseguire il deployment di workload che utilizzano un selettore di nodi per selezionare contemporaneamente le etichette di sistema e una classe ComputeClass. Se selezioni le etichette di sistema nei pod che selezionano ComputeClasses, verifica che la pianificazione dei pod avvenga come previsto. Un conflitto tra la configurazione di una ComputeClass e i selettori dei 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 ComputeClasses, aggiorna i workload per rimuovere le seguenti etichette dai selettori di nodi e configura il campo corrispondente nelle ComputeClasses 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
node.kubernetes.io/instance-type priorities.machineType

Monitoraggio dell'utilizzo di ComputeClass

Puoi monitorare il modo in cui il gestore della scalabilità automatica dei cluster interagisce con le classi di computing utilizzando le metriche di Cloud Monitoring. Metriche come kubernetes.io/autoscaler/cluster_pending_pods_per_ccc, kubernetes.io/autoscaler/cluster_node_provisioning_attempts_count_per_ccc e kubernetes.io/autoscaler/cluster_node_provisioning_failed_attempts_count_per_ccc monitorano i pod in attesa, i tentativi di provisioning dei nodi e gli errori di provisioning. Queste metriche sono disponibili su GKE versione 1.37 e successive.

Per informazioni dettagliate sull'esecuzione di query su queste metriche e sull'interpretazione delle etichette, consulta Visualizzare eventi e metriche del gestore della scalabilità automatica del cluster.

Limitazioni

  • Il nome di ComputeClass non può iniziare con gke o autopilot (riservato a ComputeClass di sistema).
  • Alcuni cluster hanno tassi elevati di creazione ed eliminazione di pod, il che aumenta il tempo di valutazione per lo strumento di scalabilità automatica del cluster. Durante un'operazione di scalabilità, il gestore della scalabilità automatica dei cluster potrebbe non avere il tempo di valutare le regole di priorità successive in una ComputeClass prima della scadenza del periodo di backoff per le regole di priorità precedenti. Di conseguenza, i pod potrebbero rimanere nello stato In attesa. Per mitigare questo problema, riduci la frequenza di creazione ed eliminazione dei pod, ad esempio disattivando la migrazione attiva per ComputeClass.

Passaggi successivi