Informazioni sulle classi di calcolo personalizzate


Questa pagina descrive come utilizzare le classi di calcolo personalizzate per controllare le proprietà dei nodi di cui Google Kubernetes Engine (GKE) esegue il provisioning durante lo scaling automatico del cluster. Questo documento è destinato 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.

Panoramica delle classi di computing

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

Le classi di calcolo personalizzate sono disponibili per l'uso in modalità GKE Autopilot e GKE Standard nella versione 1.30.3-gke.1451000 e successive e offrono un approccio dichiarativo per definire gli attributi dei nodi e le priorità di scalabilità automatica. Le classi di calcolo personalizzate sono disponibili per la configurazione e l'utilizzo in tutti i cluster GKE idonei per impostazione predefinita.

Vantaggi delle classi di calcolo personalizzate

Le classi di calcolo personalizzate offrono i seguenti vantaggi:

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

Casi d'uso per le classi di calcolo personalizzate

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

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

Come funzionano le classi di calcolo personalizzate

Le classi di calcolo personalizzate sono risorse personalizzate di Kubernetes che eseguono il provisioning dell'infrastrutturaGoogle Cloud . Definisci un oggetto ComputeClass nel cluster, quindi richiedi la classe di calcolo 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à che hai impostato nella definizione della classe di calcolo.

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

Per assicurarti che le classi di calcolo personalizzate siano ottimizzate per la tua flotta, tieni presente le seguenti linee guida:

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

Visualizza la definizione di risorsa personalizzata completa

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

Puoi anche visualizzare la CRD nel cluster eseguendo questo comando:

kubectl describe crd computeclasses.cloud.google.com

Pianificare una classe di computing personalizzata

Per pianificare, eseguire il deployment e utilizzare in modo efficace una classe di calcolo personalizzata nel cluster, svolgi i seguenti passaggi:

  1. Scegli le priorità di calcolo di riserva: definisci una serie di regole che regolano le proprietà dei nodi che GKE crea per la classe di calcolo.
  2. Configura i pool di nodi e le classi di calcolo GKE Standard: per i cluster in modalità Standard, esegui i passaggi di configurazione obbligatori per utilizzare la classe di calcolo con i pool di nodi.
  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 carichi di lavoro e rimuovere i nodi sottoutilizzati.
  5. Configura la migrazione attiva ai nodi con priorità più alta: facoltativamente, indica a GKE di spostare i carichi di lavoro sui nodi preferiti man mano che l'hardware diventa disponibile.
  6. Utilizza le prenotazioni Compute Engine: se vuoi, indica a GKE di utilizzare le prenotazioni di zona Compute Engine esistenti quando crei nuovi nodi.

Scegli le priorità di calcolo di riserva

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

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

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

Regole di priorità

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

Esistono due tipi di regole di priorità:

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

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

Regole di priorità dichiarative

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

configurazioni machineFamily

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

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

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

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

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

Il campo machineType accetta un tipo di macchina predefinita di Compute Engine, come n2-standard-32.

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

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

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

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

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

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

Il seguente esempio mostra una regola per le GPU:

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

Richiede GKE 1.31.2-gke.1518000 o versioni successive

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

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

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

Il seguente esempio mostra una regola per le TPU:

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

Questo esempio definisce il seguente comportamento di riserva:

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

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

Inoltre, per i carichi di lavoro TPU puoi:

Specifiche di acceleratori e forma della macchina

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

Regole di priorità dei node pool

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

Come GKE crea i nodi utilizzando le regole di priorità

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

Ad esempio, considera la seguente specifica:

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

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

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

Valori predefiniti per le regole 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 versione 1.32.1-gke.1729000 o successiva.
  • 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 classi di calcolo

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

Configura i node pool creati manualmente per l'utilizzo della classe di computing

Se i tuoi cluster GKE Standard hanno node pool che hai creato manualmente senza il provisioning automatico dei nodi, devi configurare questi node pool per associarli a classi di computing specifiche. GKE pianifica solo i pod che richiedono una classe di calcolo specifica sui nodi nei pool di nodi che associ a quella classe di calcolo. I pool di nodi in modalità GKE Autopilot e GKE Standard creati mediante il provisioning automatico dei nodi eseguono automaticamente questa configurazione.

Per associare un pool di nodi creato manualmente a una classe di calcolo, aggiungi etichette dei nodi e taint dei nodi al pool di nodi durante la creazione o durante un 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 classe di calcolo personalizzata.

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

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

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

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

Provisioning automatico dei nodi e classi di computing

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

Per utilizzare il provisioning automatico dei nodi con una classe di computing, devi:

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

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

Puoi utilizzare le classi di computing che interagiscono con il provisioning automatico dei nodi insieme alle classi di computing che interagiscono con i node pool creati manualmente nello stesso cluster.

Considera le seguenti interazioni con il provisioning automatico dei nodi:

  • Non puoi utilizzare i selettori di nodi famiglia di macchine o VM spot perché questi selettori sono in conflitto con il comportamento della classe di calcolo. GKE rifiuta tutti i pod che richiedono una classe di calcolo e anche VM spot o serie di macchine specifiche.
  • Puoi configurare il provisioning automatico dei nodi per le classi di computing che utilizzano il campo nodepools per fare riferimento ai pool di nodi esistenti. Il provisioning automatico dei nodi elabora le priorità in ordine e tenta di scalare i node pool esistenti per inserire i pod.

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

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: my-class
spec:
  priorities:
  - nodepools: [manually-created-pool]
  - machineFamily: n2
  - machineFamily: n2d
  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 N2, nei pool di nodi N2 esistenti o creando un nuovo node pool.
  3. Se GKE non riesce a creare nodi N2, tenta di scalare i pool di nodi N2D esistenti o di crearne di nuovi.

Target di pool di nodi specifici in una definizione di classe di computing

Il campo priorities.nodepools consente di specificare un elenco di node pool creati manualmente in cui GKE tenta di pianificare i pod senza un ordine specifico nei cluster GKE Standard che utilizzano la scalabilità automatica del cluster. Questo campo supporta solo un elenco di node pool. Non puoi specificare proprietà aggiuntive della macchina, come la serie di macchine, nella stessa regola di priorità. Quando esegui il deployment di un carico di lavoro che richiede una classe di calcolo con pool di nodi denominati, GKE tenta di pianificare i pod in attesa in questi pool di nodi. 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 quella classe di calcolo utilizzando le etichette dei nodi e i taint dei nodi, come descritto nella sezione Configurare i node pool creati manualmente per le classi di calcolo.

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

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

In questo esempio, GKE tenta innanzitutto di inserire i pod in attesa che richiedono questa classe di calcolo sui nodi esistenti nei pool di nodi etichettati con la classe di calcolo. 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 seguenti valori.

  • 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 il provisioning automatico dei nodi, GKE tenta di scalare orizzontalmente qualsiasi pool di nodi creato manualmente che definisce un'etichetta e un taint corrispondenti a una determinata classe di calcolo.
    • Nei cluster Standard che utilizzano il provisioning automatico dei nodi, GKE potrebbe creare un nuovopool di nodil che utilizza la serie di macchine E2 per posizionare il pod.
  • DoNotScaleUp: lascia il pod nello stato Pending finché non è disponibile un nodo che soddisfi i requisiti della classe di calcolo. In GKE versione 1.33 e successive, questo è il comportamento predefinito se ometti questo campo.

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

Per impostazione predefinita, GKE rimuove i nodi sottoutilizzati eseguendo i carichi di lavoro, consolidandoli su altri nodi con capacità. Per tutte le 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 carichi di lavoro su un altro nodo ed elimina il nodo svuotato.

I tempi e i criteri per la rimozione dei nodi dipendono dal profilo di scalabilità automatica. Puoi ottimizzare le soglie di sottoutilizzo delle risorse che attivano la rimozione dei nodi e il consolidamento dei workload utilizzando la sezione autoscalingPolicy nella definizione della classe di calcolo personalizzata. Puoi perfezionare 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: n2
  - machineFamily: n2d
  autoscalingPolicy:
    consolidationDelayMinutes: 5
    consolidationThreshold: 70

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

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

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

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

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

Considera la seguente specifica della classe di calcolo di esempio, che assegna la priorità ai nodi N2 rispetto ai nodi N2D:

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

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

Consumare le prenotazioni di Compute Engine

Disponibile in GKE 1.31.1-gke.2105000 e versioni successive

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

L'utilizzo delle prenotazioni nelle classi di calcolo personalizzate presenta i seguenti requisiti:

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

Prendi in considerazione la seguente specifica della classe di calcolo di esempio, che assegna la priorità a una prenotazione condivisa specifica da utilizzare durante il provisioning delle istanze a3-highgpu-1g. Se i tipi di istanza con priorità non sono disponibili, GKE 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 calcolo 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 esegue il failover sulle VM spot a3-highgpu-1g. Infine, se non sono disponibili VM spot, l'operazione di scalabilità non va a buon fine.

In questo esempio, entrambe le regole di priorità con riferimenti alla prenotazione richiedono esplicitamente il campo localSSDCount: perché la forma della macchina a3-highgpu-1g include gli 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: n2
    reservations:
      specific:
      - name: n2-shared-reservation
        project: reservation-project
      affinity: Specific
  - machineFamily: n2
    spot: true
  - machineFamily: n2
  whenUnsatisfiable: DoNotScaleUp

Puoi utilizzare i seguenti tipi di prenotazioni:

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

    • reservations.specific.name: il nome della prenotazione.
    • reservations.affinity: deve essere Specific.
  • Prenotazioni condivise specifiche: configura i seguenti campi:

    • reservations.specific.name: il nome della prenotazione.
    • reservations.specific.project: l'ID progetto del progetto proprietario della prenotazione.
    • reservations.affinity: deve essere Specific.
  • Eventuali prenotazioni corrispondenti: configura i seguenti campi:

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

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

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

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

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

Consumare blocchi di prenotazioni specifici

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

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

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

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

Quando utilizzi questa funzionalità, tieni presente quanto segue:

  • Questa funzionalità si applica solo a prenotazioni specifiche in un progetto singolo o condiviso.

Personalizzare la configurazione del sistema di nodi

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

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

Per maggiori informazioni, consulta le seguenti pagine:

Raggruppa i node pool

Puoi raggruppare più pool di nodi in un'unica unità logica chiamata raccolta utilizzando il campo nodePoolGroup nella specifica ComputeClass. Questo raggruppamento ti consente di applicare configurazioni condivise a molti pool di nodi.

Raccolta multi-host TPU

Puoi raggruppare il deployment multi-host della TPU per impostare un obiettivo del livello di servizio (SLO) in tutti i node pool all'interno della raccolta. Per raggruppare i pool di nodi, specifica il nome del gruppo nel campo nodePoolGroup. Tutti i node pool di cui è stato eseguito il provisioning utilizzando questa classe di calcolo 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 consente di applicare una configurazione che si riflette in tutti i nodi all'interno dei pool di nodi creati utilizzando quella classe.

Specifica il tipo di immagine

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

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

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

Service account

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

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

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

Definisci il tipo di workload per lo SLO TPU

Puoi definire l'obiettivo del livello di servizio (SLO) per i tuoi carichi di lavoro TPU utilizzando il campo workloadType all'interno di nodePoolConfig. Il valore in questo campo indica a GKE l'utilizzo previsto per le risorse TPU. Il campo workloadType supporta i seguenti valori:

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

L'esempio seguente definisce una classe di calcolo per una raccolta TPU multihost ottimizzata per i carichi di lavoro di inferenza ad alta disponibilità.

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

Per maggiori informazioni, consulta le seguenti pagine:

Richiedere classi di calcolo nei workload

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

Ad esempio, il seguente manifest richiede la classe di calcolo cost-optimized:

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

Passaggi successivi