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 workload specifici vengano eseguiti su hardware che soddisfa i loro requisiti. Per saperne di più su cosa sono le classi ComputeClass, consulta Informazioni sulle classi 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 classi di calcolo sono disponibili per l'utilizzo in modalità Autopilot e Standard di GKE nella versione 1.30.3-gke.1451000 e successive e offrono un approccio dichiarativo per la definizione degli attributi dei nodi e delle priorità di scalabilità automatica. Le classi ComputeClasses 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 computing di riserva: definisci una gerarchia di configurazioni dei nodi in ogni ComputeClass per assegnare la priorità a GKE. 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à a 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 workload 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 cluster, per garantire che la capacità sia disponibile per i workload critici.

Casi d'uso per le ComputeClass personalizzate

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

  • Vuoi eseguire i tuoi workload AI/ML su configurazioni GPU o TPU specifiche.
  • 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 soddisfino requisiti aziendali specifici, come prestazioni elevate, ottimizzazione dei costi 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 il parco risorse 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 classi ComputeClass personalizzate

Le classi ComputeClasses personalizzate sono risorse personalizzate di Kubernetes che eseguono il provisioning dell'infrastrutturaGoogle Cloud . Definisci un oggetto ComputeClass nel cluster, quindi richiedi la classe ComputeClass nei workload 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.
  • Scegli 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 riserva all'interno di ogni ComputeClass in modo che i workload vengano sempre eseguiti su nodi che utilizzano configurazioni della macchina simili. Ad esempio, se la serie di macchine N4 non è disponibile, puoi utilizzare le 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 tuo 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 si applicano 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. Utilizza le prenotazioni di Compute Engine: facoltativamente, indica a GKE di utilizzare le prenotazioni di zona di Compute Engine esistenti durante la creazione di nuovi nodi.
  7. Esegui il provisioning di 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 è avere il controllo sulla strategia di riserva quando i nodi preferiti non sono disponibili a causa di fattori come l'esaurimento risorsa di zona (ad esempio, la visualizzazione di messaggi ZONE_RESOURCE_POOL_EXHAUSTED o GCE out of resources durante gli eventi FailedScaleUp) e le limitazioni della quota. Definendo un elenco con priorità di serie di macchine o modelli di provisioning alternativi, il cluster può eseguire automaticamente il provisioning della capacità disponibile anziché lasciare i pod in uno stato Pending. Per ulteriori informazioni sulla risoluzione dei problemi relativi alla capacità di calcolo insufficiente, consulta La creazione del node pool non riesce a causa di risorse insufficienti e Scale up dei nodi non riuscito: Compute Engine non dispone di risorse.

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 scale up, GKE tenta di creare un nodo con queste proprietà. Ogni regola di priorità deve specificare un tipo di hardware di cui eseguire il provisioning, come descritto nella sezione Proprietà dei nodi di primo livello per le regole di priorità.

  • Selezione dei node pool: nei cluster GKE Standard, specifica i nomi dei node pool esistenti da associare alla classe 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 i 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. In questo caso, GKE elabora le regole in ordine dal punteggio più alto a quello più basso. Se tutte le regole di priorità in una classe ComputeClass sono esaurite, GKE crea i 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 sull'ordine in cui GKE elabora le regole di priorità per una classe 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 la scalabilità, GKE elabora insieme le regole con 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 limitato, 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.

L'esempio seguente 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 dei 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 utilizza la serie di macchine predefinita per il cluster.

Proprietà dei nodi 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.

Per una regola puoi utilizzare una delle seguenti proprietà di primo livello:

  • 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 della 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 che il campo machineType o machineFamily sia specificato esplicitamente, a meno che non li utilizzi 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 un oggetto 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 StorageClasses esegue il provisioning.

  • Persistent Disk preesistenti: verifica che tutte le serie di macchine nella tua ComputeClass supportino i tipi di Persistent Disk 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 abbastanza grande da 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 invece il campo machineType.

La richiesta di una famiglia di macchine più ampia non esegue il provisioning di 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: il numero minimo di vCPU 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: i 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.

L'esempio seguente 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, come n4-standard-32, o una stringa del tipo di macchina personalizzata, come 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: 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.
    • storage.localSSDCount: il numero di SSD locali da collegare al nodo. Se specificato, deve essere almeno 1.
  • enableNestedVirtualization: indica se attivare 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 macchine 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 maggiori dettagli, consulta Scegli il supporto della GPU utilizzando Autopilot o Standard.
  • gpu.count: il numero di GPU da collegare. Per le quantità supportate in base al 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, come ad esempio auto. Richiede GKE 1.35.2-gke.1842000 o versioni successive.

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

L'esempio seguente 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 versione 1.31.2-gke.1518000 o 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 di 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 località.

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 si applicano 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:

Zone AI target

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: tenta di eseguire il 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 DRANET gestito da GKE 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 Alloca le 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 si applicano 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 di 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 i node pool per una ComputeClass, devi:

  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 dei pool di nodi:

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

  • Se imposti una classe ComputeClass predefinita per il tuo cluster, i pod che utilizzano un selettore di nodi della famiglia di macchine attivano la creazione dei nodi solo per la 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 che non rientra nelle priorità della classe predefinita a livello di cluster non attiveranno la creazione dei nodi se ComputeClass ha un valore DoNotScaleUp nel campo whenUnsatisfiable.

  • Puoi configurare la creazione automatica pool di nodi per le classi ComputeClasses 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 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 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 questa ComputeClass utilizzando le etichette e le incompatibilità dei nodi, come descritto nella sezione Configura i node pool creati manualmente per le ComputeClass.

L'elenco dei node pool specificati nel campo nodepools non ha priorità. Per configurare un ordine di riserva per i node pool denominati, devi specificare più elementi priorities.nodepools separati. Ad esempio, prendi in considerazione 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 classe di computing sui nodi esistenti nei pool di nodi etichettati con la classe di computing. 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 della macchina predefinita 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 dei pool di nodi, GKE tenta di fare lo scale up di qualsiasi pool di nodi creato manualmente che definisce un'etichetta e una contaminazione corrispondenti a una determinata classe di calcolo.
    • Nei cluster Standard che utilizzano la creazione automatica dei 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 soddisfa 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 del 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 workload che utilizzano questa ComputeClass ed esegue il provisioning dei relativi nodi in base alla policy delle 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 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 della CPU e della memoria come percentuale delle risorse disponibili del nodo. GKE prende in considerazione i nodi per la rimozione 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 i nodi per la rimozione solo se l'utilizzo delle risorse è inferiore a questa soglia. Valuta la possibilità di impostare questo valore su 100 o su 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 per il consolidamento solo se l'utilizzo della CPU e della memoria è inferiore al 70%.

Migrazione attiva

La migrazione attiva è una funzionalità di scalabilità automatica facoltativa di 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 fornisce il recupero automatico dopo una carenza temporanea di capacità a livello di zona (ZONE_RESOURCE_POOL_EXHAUSTED). Questa opzione aiuta a garantire che i pod stateless o tolleranti alle interruzioni tornino alla configurazione dei nodi preferita, anche se GKE ha dovuto inizialmente eseguire il provisioning dell'hardware di riserva da una regola con priorità inferiore.
  • ensureAllDaemonSetPodsRunning: GKE sostituisce i nodi con pod DaemonSet non pianificabili con nodi più grandi che possono 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:

  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, il che comporta l'espulsione dei pod dal nodo. I seguenti fattori influiscono sulla rapidità con cui viene svuotato il nodo:

    I controller Kubernetes, come i deployment o i job, creano pod per sostituire quelli espulsi. 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 viola 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 uno spazio di archiviazione permanente, come i dischi permanenti di Compute Engine. Per ridurre al minimo il rischio di perdita di dati, non attivare la migrazione attiva in ComputeClasses utilizzate dai workload stateful.
  • Nei cluster Standard, se utilizzi la creazione automatica dei pool di nodi, la migrazione attiva potrebbe attivare la creazione di nuovi node pool se quelli esistenti non soddisfano i criteri definiti nella tua ComputeClass.
  • I workload 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à superiore.

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, ad esempio a causa di una carenza temporanea di risorsa di zona (ZONE_RESOURCE_POOL_EXHAUSTED), GKE avrebbe utilizzato i nodi C4 come opzione di riserva. Quando la capacità N4 viene ripristinata nella tua località o la tua quota aumenta, GKE esegue automaticamente la migrazione dei workload ai nodi N4:

  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 espulsi. 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 con un singolo pod che ha utilizzato questa ComputeClass e ha richiesto 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 tuo 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.

Utilizza 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 di Compute Engine utilizzando una classe 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 dei node pool e ComputeClasses.
  • Node pool creati manualmente: sui cluster in modalità Standard, puoi indirizzare i workload ai node pool creati manualmente specificando il campo spec.priorities.nodepools nella tua ComputeClass.

A partire dalla versione 1.36.0-gke.3204000 di GKE, puoi configurare i workload in modo che utilizzino qualsiasi prenotazione corrispondente senza dover ricorrere 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. La classe ComputeClass che implementa queste preferenze è simile all'esempio seguente:

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 posizionare i pod prima in reservation-pool-1, perché questa regola di priorità appare 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 che GKE utilizzi 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 classi ComputeClasses che configurano gli SSD locali devono utilizzare la regola di priorità machineType, non machineFamily. Per maggiori dettagli, consulta la sezione Tipo di regola machineType.
  • Le classi ComputeClasses che specificano le prenotazioni per un machineType con SSD locali collegati devono includere esplicitamente un campo localSSDCount:.

Considera il seguente esempio di specifica ComputeClass, che dà 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 fare lo scale up delle 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 fallback alle VM spot e infine alle 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 per singolo progetto specifiche: 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 nella classe ComputeClass.
  • Qualsiasi prenotazione corrispondente con riserva (AnyBestEffort): GKE tenta di eseguire il provisioning di un nodo on demand che soddisfi i requisiti della 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.
  • Qualsiasi prenotazione corrispondente senza fallback (AnyThenFail): GKE ignora il provisioning di un nodo on demand e prova la regola di priorità successiva nella classe ComputeClass. Se non si applicano altre regole, l'operazione di scalabilità non va a buon fine 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.

Utilizza 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 Utilizza 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.

Numero minimo di 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 funziona bene per i workload che richiedono una quantità di base di capacità di calcolo, come l'addestramento di AI/ML di grandi dimensioni o i workload di distribuzione 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 classe ComputeClass o una regola di priorità, tieni presente 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 attivi 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 quella 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 prerilasciare 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 classi ComputeClass che utilizzano configurazioni flessibili in una regola di priorità, come il campo machineFamily, e che specificano anche una capacità minima per l'intera classe 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 seconda regola di priorità. 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 1.32.1-gke.1729000 e versioni 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 classe 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 il taint predefinito dell'architettura Arm

Per impostazione predefinita, GKE aggiunge la taint kubernetes.io/arch=arm64:NoSchedule a tutti i nodi Arm, inclusi quelli creati per le classi ComputeClasses personalizzate. GKE pianifica solo i workload che hanno una tolleranza per questa contaminazione sui nodi Arm, il che aiuta a impedire l'esecuzione dei 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 non ha la tolleranza per l'architettura Arm.

Puoi aggiornare il comportamento predefinito dei taint nei node pool Standard e con i nodi creati per le classi ComputeClasses 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 esegua GKE versione 1.36.2-gke.1498000 o successiva.

ComputeClasses predefinite per cluster e spazi dei nomi

Puoi configurare GKE in modo che applichi una classe ComputeClass per impostazione predefinita ai pod che non selezionano una classe ComputeClass specifica. Puoi definire una classe 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.

Node pool di gruppo

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 più pool di nodi.

Raccolta TPU multi-host

Richiede GKE versione 1.31.2-gke.1518000 o 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 node pool 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 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 classe ComputeClass per una raccolta TPU multi-host ottimizzata per i workload di inferenza ad alta affidabilità.

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 versione 1.36.2-gke.1368000 o successive

Puoi isolare i workload 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 è stato eseguito il provisioning per i tuoi node pool tramite il gestore della scalabilità automatica dei cluster o il 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 sia 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 massima combinata di tutte le coppie chiave-valore dei metadati nell'intera risorsa ComputeClass non può superare i 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 i metadati delle istanze globali in tutti i node pool e 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 più rigidi alle risorse per una specifica ComputeClass, ad esempio limitando il numero massimo di GPU, CPU o nodi totali di cui è possibile eseguire il 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 versione 1.36.3-gke.1244000 o 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

Richiedi ComputeClasses 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 di 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 i pod vengano pianificati 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 su come eseguire query su queste metriche e interpretare le etichette, consulta Visualizza gli eventi e le metriche del gestore della scalabilità automatica dei cluster.

Limitazioni

  • Il nome di ComputeClass non può iniziare con gke o autopilot (riservato alle ComputeClass di sistema).
  • Alcuni cluster hanno tassi elevati di creazione ed eliminazione di pod, il che aumenta il tempo di valutazione per il gestore della scalabilità automatica dei 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 in 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