Risolvere i problemi relativi a ComputeClass personalizzate

Questo documento ti aiuta a risolvere i problemi relativi al mancato scheduling dei carichi di lavoro GKE sui nodi definiti da una ComputeClass personalizzata o quando lo strumento di scalabilità automatica del cluster non esegue il provisioning dei tipi di macchina previsti.

Questo documento è destinato a sviluppatori di applicazioni, amministratori e operatori di piattaforme che utilizzano ComputeClass personalizzate per gestire la pianificazione dei workload e la creazione automatica di pool di nodi in GKE. Per maggiori informazioni sui ruoli comuni e sulle attività di esempio a cui viene fatto riferimento nei contenuti di Google Cloud , consulta Ruoli e attività utente GKE comuni.

Concetti fondamentali

Per facilitare la risoluzione dei problemi, assicurati di conoscere i seguenti componenti e meccanismi di GKE:

  • Custom ComputeClass: una risorsa specifica di GKE che consente di definire un elenco prioritario di configurazioni dei nodi per la scalabilità automatica. Per ulteriori informazioni, vedi Informazioni su ComputeClass personalizzate.

  • Gestore della scalabilità automatica dei cluster: il componente che aggiunge o rimuove automaticamente i nodi nel cluster in base alla domanda del carico di lavoro. Per saperne di più, consulta Informazioni sulla scalabilità automatica dei cluster GKE.

  • Creazione automatica di node pool: il gestore della scalabilità automatica dei cluster GKE crea e gestisce automaticamente i node pool in base ai requisiti del workload. Per saperne di più, consulta Informazioni sulla creazione automatica del pool di nodi.

  • Logica di fallback: il meccanismo in cui il gestore della scalabilità automatica dei cluster tenta di eseguire il provisioning dei nodi corrispondenti alla regola con la priorità più alta. Per saperne di più, vedi Scegliere le priorità di calcolo di riserva.

Risolvere i problemi in base ai sintomi

Questo documento organizza i passaggi per la risoluzione dei problemi in sequenza, dai controlli fondamentali alle configurazioni più avanzate. Per una diagnosi più completa, ti consigliamo di eseguire questi passaggi nell'ordine indicato. In alternativa, se riscontri problemi specifici, consulta i link pertinenti nella tabella seguente:

Sintomo Passaggi per la risoluzione dei problemi
Il pod che richiede una ComputeClass personalizzata è bloccato nello stato Pending
Il gestore della scalabilità automatica del cluster non crea nuovi nodi che corrispondono a ComputeClass personalizzata
Il gestore della scalabilità automatica del cluster crea tipi di macchine predefiniti anziché tipi specializzati Analizzare il comportamento di fallback del gestore della scalabilità automatica
L'output del comando kubectl describe computeclass mostra uno stato non integro Verificare le configurazioni personalizzate di ComputeClass
I workload non vengono migrati a nodi con priorità più alta Verifica l'integrità generale del gestore della scalabilità automatica del cluster
I carichi di lavoro delle VM GPU o spot presentano problemi di pianificazione

Problemi fuori ambito

Questo documento non tratta i seguenti problemi:

  • Problemi di rete GKE generali, come la connettività da pod a pod o il bilanciamento del carico del servizio.
  • Problemi relativi a Horizontal Pod Autoscaler (HPA) o Vertical Pod Autoscaler (VPA).
  • Problemi non correlati al meccanismo ComputeClass personalizzato, ad esempio errori a livello di applicazione o problemi di PersistentVolume non correlati a vincoli di pianificazione.
  • Problemi di quota o indisponibilità delle risorse che non sono direttamente correlati alla logica di fallback di ComputeClass.

Identificare le variabili segnaposto

Per personalizzare i comandi in questo documento, inserisci i tuoi valori specifici nella colonna Variable. I valori modificati vengono sincronizzati automaticamente in tutti i blocchi di codice e i comandi.

Variabile Descrizione
PROJECT_ID L'ID progetto Google Cloud .
LOCATION La regione o la zona di Compute Engine in cui si trova il cluster.
CLUSTER_NAME Il nome del cluster.
NODE_POOL_NAME Il nome del pool di nodi da esaminare (se applicabile ai cluster Standard).
CUSTOM_COMPUTECLASS_NAME Il nome di ComputeClass personalizzata richiesta dal pod.
NAMESPACE Lo spazio dei nomi del pod la cui pianificazione non è riuscita.
POD_NAME Il nome del pod la cui pianificazione non è riuscita.

Prima di iniziare

Per ottenere le autorizzazioni necessarie per eseguire le attività descritte in questo documento, chiedi all'amministratore di concederti i seguenti ruoli IAM nel tuo progetto Google Cloud :

  • Per accedere ai cluster GKE: Visualizzatore cluster Kubernetes Engine (roles/container.viewer).
  • Per visualizzare i log: Visualizzatore log (roles/logging.viewer).
  • Per gestire i cluster GKE: Amministratore Kubernetes Engine (roles/container.admin).

Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Per configurare kubectl in modo che comunichi con il cluster, esegui questo comando:

  gcloud container clusters get-credentials CLUSTER_NAME
      --location LOCATION
      --project PROJECT_ID

Eseguire controlli diagnostici di base

Verifica che i componenti principali siano configurati correttamente e che il cluster supporti ComputeClass personalizzate.

Verifica lo stato e il selettore del pod

Verifica che il pod sia nello stato Pending e richieda correttamente la ComputeClass personalizzata.

  1. Elenca i pod nello stato Pending:

    kubectl get pods --all-namespaces -o wide | grep Pending

  2. Esamina la specifica del pod per il campo nodeSelector:

    kubectl get pod POD_NAME
    -n NAMESPACE
    -o jsonpath='{.spec.nodeSelector}'

Valutare il risultato

  • L'output mostra l'etichetta:il campo nodeSelector è configurato correttamente con l'etichetta cloud.google.com/compute-class.
  • L'output non mostra l'etichetta:
    • Interpretazione:potrebbe esserci un campo nodeSelector errato o mancante per l'etichetta cloud.google.com/compute-class nella configurazione di deployment del tuo workload.
    • Risoluzione:modifica il file YAML del carico di lavoro, ad esempio un deployment o un job, in modo da includere il campo nodeSelector nella sezione spec.template.spec.

Verifica la compatibilità della versione del cluster

Le ComputeClass personalizzate richiedono GKE versione 1.30.3-gke.1451000 o successive. Verifica che il cluster esegua una versione che supporta ComputeClass personalizzate.

Controlla la versione del cluster:

gcloud container clusters describe CLUSTER_NAME
    --location LOCATION
    --format="value(currentMasterVersion)"

Valutare il risultato

  • Versione 1.30.3-gke.1451000 o successive:la tua versione del cluster supporta ComputeClass personalizzate.
  • Versione precedente a 1.30.3-gke.1451000:
    • Interpretazione:il cluster non è stato aggiornato a una versione che supporta ComputeClass personalizzate.
    • Risoluzione:per utilizzare ComputeClass personalizzate, devi eseguire l'upgrade del cluster.

Verifica le configurazioni personalizzate di ComputeClass

Errori di configurazione nella risorsa ComputeClass personalizzata possono impedire la pianificazione dei pod o il provisioning corretto dei nodi da parte di GKE.

Controllare l'integrità e lo stato di ComputeClass

Verifica che GKE segnala che ComputeClass personalizzata è integra.

  1. Elenca tutte le risorse ComputeClass:

    kubectl get computeclass

  2. Descrivi la risorsa ComputeClass specifica:

    kubectl describe computeclass CUSTOM_COMPUTECLASS_NAME

Valutare il risultato

  • Lo stato di integrità mostra True:la ComputeClass personalizzata è integra. Di seguito è riportato un esempio di ComputeClass personalizzata integra:

    Status:
  Conditions:
    Last Transition Time:  2024-01-19T17:18:48Z
    Message:               CCC is healthy.
    Reason:                Health
    Status:                True
    Type:                  Health

  • Lo stato di integrità mostra False:

    • Interpretazione:ComputeClass personalizzata non è integra. Esamina i campi Message e Reason nell'output per identificare il problema.
    • Risoluzione:esegui l'azione corrispondente al campo Reason nell'output:
      • NodePoolNotExist: assicurati che il pool di nodi a cui viene fatto riferimento esista o aggiorna ComputeClass in modo che faccia riferimento a un pool di nodi esistente.
      • ReservationUnusable: controlla la configurazione e l'utilizzo della prenotazione a cui viene fatto riferimento.
      • Invalid machine type: aggiorna ComputeClass per utilizzare un tipo di macchina supportato nella regione o nella zona del cluster.

Convalida il criterio unsatisfiable

Il campo whenUnsatisfiable determina il comportamento quando non è possibile soddisfare regole di priorità.

Controlla le norme:

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

Esamina il campo spec.whenUnsatisfiable nell'output. Questo campo può contenere uno dei seguenti valori:

  • DoNotScaleUp: i pod rimangono nello stato Pending se non è possibile creare nodi preferiti.
  • ScaleUpAnyway: i pod potrebbero essere eseguiti su tipi di nodi predefiniti (come la serie E2) se i nodi preferiti non sono disponibili.

Valutare il risultato

L'effetto del criterio whenUnsatisfiable dipende dal suo valore:

  • Se il valore è DoNotScaleUp:
    • Interpretazione:questo è il comportamento previsto quando non è possibile soddisfare alcuna regola di priorità, probabilmente a causa dell'indisponibilità delle risorse o dei limiti di quota. Se i pod devono attendere hardware specifici, questo valore è corretto.
    • Risoluzione:se l'esecuzione del workload è più importante dell'esecuzione su hardware specifico, modifica il criterio in ScaleUpAnyway.
  • Se il valore è ScaleUpAnyway:
    • Interpretazione:si tratta di un comportamento previsto. GKE sta eseguendo il failover sui tipi di nodi predefiniti perché i nodi preferiti non sono disponibili.
    • Risoluzione:se i pod non devono essere eseguiti sui tipi di nodi predefiniti, modifica il criterio in DoNotScaleUp.
  • Comportamento predefinito:se non hai specificato un valore per il campo whenUnsatisfiable e utilizzi una versione di GKE precedente alla 1.33, il criterio viene impostato per impostazione predefinita su ScaleUpAnyway.

Il seguente esempio mostra come aggiornare la policy modificando il campo whenUnsatisfiable nel manifest ComputeClass:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: CUSTOM_COMPUTECLASS_NAME
spec:
  # ... other fields
  whenUnsatisfiable: DoNotScaleUp # or ScaleUpAnyway

Controllare i vincoli di pianificazione dei pod

Assicurati che la specifica del pod sia compatibile con gli attributi dei nodi di cui è stato eseguito il provisioning dalla ComputeClass personalizzata.

Verifica le richieste di risorse pod

Controlla se le richieste di CPU, memoria e GPU del pod possono essere soddisfatte da almeno uno dei tipi di macchina definiti nel campo priorities di ComputeClass personalizzata.

  1. Recupera le richieste di risorse del pod:

    kubectl get pod POD_NAME
    -n NAMESPACE
    -o jsonpath='{.spec.containers[*].resources.requests}'

    Controlla l'output per cpu, memory e le richieste di GPU, ad esempio nvidia.com/gpu.

  2. Confronta queste richieste con i tipi di macchine definiti nel campo priorities della ComputeClass personalizzata:

    kubectl get computeclass CUSTOM_COMPUTECLASS_NAME
    -o jsonpath='{.spec.priorities}'

    Esamina l'output per i campi machineType o machineFamily. Per ogni tipo di macchina nella ComputeClass personalizzata, controlla le specifiche nella documentazione sui tipi di macchine e verifica se le risorse allocabili sono maggiori delle richieste del pod.

Valutare il risultato

  • Risorse compatibili:le richieste di risorse del pod sono inferiori o uguali alle risorse allocabili di almeno un tipo di macchina in ComputeClass.

  • Le risorse superano la capacità:

    • Interpretazione:non è possibile pianificare il pod perché nessun tipo di macchina in ComputeClass fornisce CPU, memoria o GPU sufficienti. Ciò può verificarsi anche se il campo nodePoolAutoCreation è impostato su true e la richiesta di memoria del pod supera i limiti dei node pool creati automaticamente.
    • Soluzione:modifica le richieste di risorse del pod o i tipi di macchina della ComputeClass personalizzata:
      • Riduci le richieste di risorse dei pod: se le richieste di risorse sono elevate, riduci i valori cpu, memory o gpu nel file YAML del workload.
      • Passa a tipi di macchina più grandi: se le richieste del pod sono giustificate, modifica il campo spec.priorities nel manifest ComputeClass personalizzato in modo da includere opzioni machineType o machineFamily più grandi che possano soddisfare le richieste del pod. Ad esempio:
    spec:
  priorities:
  - machineType: n2d-highmem-96 # A larger machine type
    spot: true
  # ... other priorities

Verifica la presenza di incompatibilità e tolleranze in conflitto

I nodi creati per una ComputeClass personalizzata hanno il taint cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule. GKE aggiunge automaticamente questa tolleranza ai pod.

Tuttavia, hardware specializzato come le GPU ha ulteriori taint, ad esempio il taint nvidia.com/gpu=present:NoSchedule. Se ComputeClass utilizza nodi con hardware specializzato, i pod devono avere una tolleranza per questi taint per la pianificazione su questi nodi.

Controlla il campo tolerations del pod:

kubectl get pod POD_NAME
    -n NAMESPACE
    -o jsonpath='{.spec.tolerations}'

Valutare il risultato

  • Tolleranze corrette:i taint e le tolleranze sono configurati correttamente.

  • Tolleranze mancanti:

    • Interpretazione:le tolleranze mancanti impediscono la pianificazione del pod sui nodi con incompatibilità hardware specializzate. Ad esempio, se ComputeClass utilizza nodi GPU, il pod potrebbe non avere la tolleranza nvidia.com/gpu=present:NoSchedule. Per i requisiti specifici della GPU, consulta Verifica della configurazione della GPU.

    • Soluzione:nel campo tolerations delle specifiche del pod, aggiungi le tolleranze necessarie per corrispondere alle incompatibilità sui nodi definiti da ComputeClass. Ad esempio, per i nodi GPU, aggiungi una tolleranza per il taint nvidia.com/gpu=present:NoSchedule nel seguente modo:

      spec:
template:
spec:
tolerations:
- key: "nvidia.com/gpu"
operator: "Exists"
effect: "NoSchedule"
# ... other tolerations and Pod spec

Configurazione del node pool (cluster standard)

Nei cluster GKE Standard, i node pool creati manualmente devono essere etichettati e contrassegnati per funzionare con una ComputeClass personalizzata.

Verifica le etichette e le incompatibilità del pool di nodi

  1. Identifica i pool di nodi nella ComputeClass personalizzata. Se la ComputeClass personalizzata utilizza il campo nodePools, annota i nomi dei pool di nodi elencati:

    kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

  2. Per ogni pool di nodi che hai identificato, verifica la configurazione:

    gcloud container node-pools describe NODE_POOL_NAME
    --cluster CLUSTER_NAME
    --location LOCATION
    --format="yaml(config.labels, config.taints)"

Valutare il risultato

  • Pool di nodi configurato correttamente:il pool di nodi ha l'etichetta cloud.google.com/compute-class: CUSTOM_COMPUTECLASS_NAME e il taint cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule.

  • Node pool configurato in modo errato:

    • Interpretazione:il pool di nodi non è stato configurato con l'etichetta e il taint necessari per associarlo a ComputeClass personalizzata.

    • Risoluzione:aggiorna il pool di nodi per aggiungere l'etichetta e il taint:

      1. Aggiungi o aggiorna l'etichetta del nodo:

        gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME --location=LOCATION \
    --node-labels=cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME

      2. Aggiungi o aggiorna il taint del nodo:

        gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME --location=LOCATION \
    --node-taints=cloud.google.com/compute-class=CUSTOM_COMPUTECLASS_NAME:NoSchedule

Verifica della configurazione della creazione automatica del pool di nodi

Per i cluster Autopilot e Standard con nodePoolAutoCreation impostato su true, la creazione automatica pool di nodi deve essere configurata correttamente.

Verifica che la creazione automatica pool di nodi sia abilitata

  1. Controlla se il campo nodePoolAutoCreation.enabled in ComputeClass personalizzata è impostato su true:

    kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

  2. Controlla se la creazione automatica pool di nodi è abilitata sul cluster:

    gcloud container clusters describe CLUSTER_NAME
    --location LOCATION
    --format="value(autoscaling.enableNodeAutoprovisioning)"

Se uno dei due è disabilitato, la creazione automatica del pool di nodi non creerà nuovi pool di nodi per la tua ComputeClass personalizzata.

Valutare il risultato

  • Creazione automatica del node pool abilitata:in ComputeClass, il campo nodePoolAutoCreation.enabled è impostato su true e il provisioning automatico dei nodi è abilitato a livello di cluster.

  • Creazione automatica del node pool disabilitata:

    • Interpretazione:la creazione automatica del pool di nodi è disabilitata se il valore del campo nodePoolAutoCreation.enabled è false o non è presente in ComputeClass oppure se il provisioning automatico dei nodi a livello di cluster è disabilitato.

    • Soluzione:abilita la creazione automatica del pool di nodi:

      1. Modifica il file YAML ComputeClass personalizzato in modo che includa nodePoolAutoCreation: enabled: true:

        spec:
  # ... priorities
  nodePoolAutoCreation:
    enabled: true

      2. Abilita la creazione automatica pool di nodi a livello di cluster e configura i limiti delle risorse:

        gcloud container clusters update CLUSTER_NAME --location LOCATION \
  --enable-autoprovisioning \
  --autoprovisioning-min-cpu=MIN_CPU \
  --autoprovisioning-max-cpu=MAX_CPU \
  --autoprovisioning-min-memory=MIN_MEMORY \
  --autoprovisioning-max-memory=MAX_MEMORY

Controlla i limiti delle risorse per la creazione automatica del pool di nodi

La creazione automatica di node pool ha limiti a livello di cluster per CPU e memoria. Se l'utilizzo attuale del cluster più le risorse di un nuovo nodo superano questi limiti, la creazione automatica del pool di nodi non eseguirà il provisioning di nuovi nodi.

  1. Visualizza i limiti delle risorse:

    gcloud container clusters describe CLUSTER_NAME
    --location LOCATION
--format="value(autoscaling.resourceLimits)"

    L'output elenca i campi resourceType, minimum e maximum per CPU e memoria (in GB).

  2. Esamina i tipi di macchina nelle priorità di ComputeClass personalizzata. Controlla le specifiche di CPU e memoria nella documentazione sui tipi di macchine.

  3. Determina la capacità totale attuale di CPU e memoria di tutti i nodi nel cluster. La somma della capacità attuale più le risorse di un potenziale nuovo nodo non deve superare il limite massimo per la creazione automatica del pool di nodi.

Valutare il risultato

  • Capacità sufficiente:il cluster ha una capacità di CPU e memoria sufficiente entro i limiti delle risorse per il provisioning di un nuovo nodo mediante la creazione automatica del pool di nodi.

  • Limiti superati:

    • Interpretazione:la creazione automatica del pool di nodi non può eseguire il provisioning di nuovi nodi perché il cluster ha raggiunto i limiti di CPU o memoria oppure i limiti sono stati impostati troppo bassi per i tipi di macchine in ComputeClass.

    • Soluzione: aumenta i limiti delle risorse per la creazione automatica del pool di nodi:

      1. Determina nuovi limiti massimi che tengano conto dell'utilizzo attuale e della crescita futura, inclusi i tipi di macchine più grandi nella ComputeClass personalizzata.

      2. Aggiorna i limiti delle risorse per la creazione automatica del node pool. Puoi impostare più risorse in un unico comando:

        gcloud container clusters update CLUSTER_NAME --location LOCATION \
  --set-nap-resource-limits resourceType=cpu,maximum=NEW_MAX_CPU \
  --set-nap-resource-limits resourceType=memory,maximum=NEW_MAX_GB

Analizza il comportamento di fallback del gestore della scalabilità automatica

Questa sezione ti aiuta a esaminare i fattori esterni per capire perché il gestore della scalabilità automatica dei cluster potrebbe ignorare le opzioni preferite e utilizzare i fallback o non riuscire a eseguire lo scale up.

Le ComputeClass personalizzate utilizzano una logica di fallback con priorità. Se un pod non viene pianificato sui nodi corrispondenti alla regola con la priorità più alta, spesso è dovuto a vincoli come la mancata disponibilità delle risorse o le quote del progetto. Quando GKE non riesce a eseguire il provisioning dei nodi corrispondenti a una regola di priorità specifica, ad esempio a causa di un errore ZONE_RESOURCE_POOL_EXHAUSTED o QUOTA_EXCEEDED di Compute Engine, lo strumento di scalabilità automatica del cluster prova immediatamente la regola successiva nell'elenco priorities. Non è previsto un periodo di attesa prima che GKE esegua il failover alla priorità successiva, tranne quando si utilizzano TPU o il modello di provisioning con avvio flessibile, che supportano un ritardo configurabile.

Controllare l'indisponibilità delle risorse

Verifica se le risorse non sono disponibili nella zona specificata controllando i log del gestore della scalabilità automatica del cluster o gli errori del gruppo di istanze gestite (MIG) di Compute Engine.

Opzione 1: controlla gli eventi di visibilità del gestore della scalabilità automatica dei cluster

Nella console Google Cloud , vai a Cloud Logging > Esplora log ed esegui la seguente query per trovare eventi di scalabilità automatica che potrebbero indicare l'indisponibilità delle risorse:

resource.type="k8s_cluster"
resource.labels.location="LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.noScaleUpReason.messageId="no.scale.up.nap.resource.exhausted"

Opzione 2: controlla gli errori del gruppo di istanze gestite

Puoi verificare la presenza di errori MIG nella console Google Cloud o utilizzando una query Cloud Logging.

  • Utilizzo della console Google Cloud :

    1. Nella console Google Cloud , vai a Compute Engine > Gruppi di istanze.
    2. Trova il MIG corrispondente al pool di nodi per cui non è possibile eseguire lo scale up.
    3. Fai clic sul nome del MIG e vai alla scheda Errori. Cerca messaggi che indicano l'esaurimento delle risorse.

  • Utilizzo della query Cloud Logging:

    1. Nella console Google Cloud , vai a Cloud Logging > Esplora log.
    2. Esegui la seguente query per verificare la presenza di errori di esaurimento delle risorse dal MIG:
    resource.type="gce_instance"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.status.message:("ZONE_RESOURCE_POOL_EXHAUSTED" OR "does not have enough resources available to fulfill the request" OR "resource pool exhausted" OR "does not exist in zone")

Valutare il risultato

  • Le risorse sono disponibili:se i log non mostrano i messaggi ZONE_RESOURCE_POOL_EXHAUSTED, è improbabile che l'indisponibilità delle risorse sia la causa dell'errore di scalabilità verticale.

  • Le risorse non sono disponibili:

    • Interpretazione:il provisioning dei nodi non riesce a causa di un'elevata domanda temporanea di un tipo di macchina specifico (in particolare VM spot o GPU) in quella zona oppure perché un pod è vincolato dall'affinità PersistentVolume a una zona che presenta indisponibilità di risorse.

    • Risoluzione:l'indisponibilità delle risorse è temporanea, ma puoi migliorare la resilienza aggiungendo flessibilità alla configurazione:

      • Diversifica i tipi di macchine: assicurati che il campo spec.priorities in ComputeClass personalizzata contenga più tipi o famiglie di macchine come fallback:

        spec:
  priorities:
  - machineFamily: c3  # Highest priority
  - machineFamily: n2d # Fallback option
  - machineFamily: e2  # Lowest priority

      • Utilizza cluster regionali: se il cluster è zonale, è vulnerabile all'indisponibilità delle risorse in quella singola zona. L'utilizzo di cluster regionali consente al gestore della scalabilità automatica del cluster di tentare di eseguire il provisioning dei nodi in altre zone all'interno della regione in cui potrebbe essere disponibile capacità.

      • Utilizza le prenotazioni di Compute Engine: per i carichi di lavoro critici che non possono tollerare ritardi, crea prenotazioni di Compute Engine per garantire la capacità per tipi di macchine specifici.

Verifica delle quote del progetto

Verifica che il tuo progetto disponga di una quota sufficiente per le risorse, come CPU, GPU e indirizzi IP richiesti dai nuovi nodi.

  1. Controlla i log del gestore della scalabilità automatica per verificare la presenza di errori relativi alla quota. Utilizza Cloud Logging per cercare messaggi di errore relativi alla quota negli eventi di visibilità del gestore della scalabilità automatica:

    resource.type="k8s_cluster"
resource.labels.location="LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
log_id("container.googleapis.com/cluster-autoscaler-visibility")
jsonPayload.noScaleUpReason.messageId="no.scale.up.nap.quota.exceeded"

    In alternativa, utilizza la seguente query Cloud Logging per controllare i log relativi agli errori correlati alle quote del gruppo di istanze gestite:

    resource.type="gce_instance"
protoPayload.methodName:"compute.instances.insert"
protoPayload.status.message:"QUOTA_EXCEEDED"
severity=ERROR

  2. Esamina le quote nella console Google Cloud :

    1. Nella console Google Cloud , vai a IAM e amministrazione > Quote.
    2. Filtra il servizio API Compute Engine.
    3. Controlla l'utilizzo delle metriche pertinenti, come CPU, GPU (di tutti i tipi) e indirizzi IP in uso per la regione in cui si trova il cluster GKE. Verifica che l'utilizzo attuale non abbia raggiunto il limite.

Valutare il risultato

  • Quota al di sotto dei limiti:se l'utilizzo della quota è inferiore ai limiti della quota e nei log non vengono rilevati errori QUOTA_EXCEEDED, i limiti della quota non bloccheranno lo scale up.
  • Quota superata:
    • Interpretazione:il provisioning dei nodi non riesce a causa di una quota insufficiente per risorse come CPU, GPU, indirizzi IP o MIG.
    • Risoluzione:se il tuo progetto ha raggiunto un limite di quota, richiedi un aumento della quota.

Configurazioni avanzate

Configurazioni come GPU, VM spot e prenotazioni di Compute Engine hanno requisiti specifici e potenziali punti di errore che devono essere controllati.

Verifica la configurazione della GPU

Per le ComputeClass personalizzate che eseguono il provisioning dei nodi GPU, convalida la configurazione della GPU nella ComputeClass personalizzata e assicurati che il pod abbia la tolleranza nvidia.com/gpu obbligatoria.

  1. Controlla il file YAML di ComputeClass personalizzato per un blocco gpu all'interno di una regola di priorità:

    kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

    Il blocco gpu deve specificare un campo type e un campo count, ad esempio:

    priorities:
- machineType: a2-highgpu-1g
  gpu:
    type: nvidia-tesla-a100
    count: 1

  2. Ispeziona il pod per la tolleranza della GPU. Qualsiasi pod che deve essere pianificato su un nodo GPU deve avere la tolleranza nvidia.com/gpu, anche se il pod non richiede una GPU.

    kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.tolerations}'

    Controlla la tolleranza nel campo spec.tolerations.

Valutare il risultato

  • GPU configurata correttamente:se ComputeClass definisce GPU type e count e i pod includono la tolleranza nvidia.com/gpu, la configurazione della GPU è corretta. Di seguito è riportata la tolleranza richiesta:

    tolerations:
- key: "nvidia.com/gpu"
  operator: "Exists"
  effect: "NoSchedule"

  • GPU configurata in modo errato:

    • Interpretazione:il pod potrebbe non avere la tolleranza nvidia.com/gpu richiesta, la ComputeClass potrebbe non essere integra a causa di mancate corrispondenze del campo GPU o la versione di GKE potrebbe non gestire correttamente la configurazione della GPU.
    • Risoluzione:esegui una delle seguenti operazioni:
      • Modifica il file YAML del workload per includere la tolleranza GPU obbligatoria e riapplica il file YAML.
      • Esegui l'upgrade del cluster GKE. Se la ComputeClass personalizzata non è integra e il problema riguarda i campi GPU, controlla se sono presenti problemi noti ed esegui l'upgrade a una versione di GKE con patch, ad esempio 1.31.8-gke.1045000 o successive.

Verifica la configurazione delle VM spot

Se utilizzi le VM spot, assicurati che l'impostazione spot: true si trovi nelle regole di priorità corrette nel manifest ComputeClass. Inoltre, assicurati di comprendere la logica di determinazione dei prezzi del gestore della scalabilità automatica dei cluster.

Controlla il manifest ComputeClass:

kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

Nell'output, cerca spot: true nel campo spec.priorities, ad esempio:

priorities:
- machineFamily: n2d
  spot: true

Lo strumento di scalabilità automatica del cluster potrebbe utilizzare i dati sui prezzi di us-central1 come base di riferimento quando confronta il costo di diversi tipi di VM spot, il che può portare a scelte apparentemente non ottimali in altre regioni. Questo è un comportamento noto.

Valutare il risultato

  • VM spot configurate correttamente:se il campo spot: true è specificato e il gestore della scalabilità automatica del cluster esegue il provisioning delle VM spot, la configurazione funziona come previsto.

  • Impossibile pianificare le VM spot:

    • Interpretazione:i pod che richiedono VM spot potrebbero non essere pianificati sulle VM spot a causa della mancata disponibilità di risorse nella zona di destinazione oppure perché lo strumento di scalabilità automatica del cluster potrebbe scegliere un tipo di VM diverso in base al modello di prezzi us-central1.

    • Risoluzione:

      • Se sospetti che una risorsa non sia disponibile, consulta Verificare l'indisponibilità di una risorsa.

      • Per controllare la selezione delle VM spot, elenca esplicitamente le voci machineType nel campo priorities dalla più economica alla più costosa per la tua regione. Questo approccio ti consente di controllare direttamente l'ordine di fallback. Ad esempio:

        spec:
  priorities:
  - machineType: t2d-standard-48 # Cheapest in this region
    spot: true
  - machineType: n2d-standard-48 # Fallback Spot option
    spot: true
  - machineType: n2d-standard-48 # On-demand fallback
    spot: false

Stato generale del gestore della scalabilità automatica del cluster

Questa sezione ti aiuta a verificare la presenza di problemi che potrebbero non essere direttamente correlati alla configurazione personalizzata di ComputeClass, ma che potrebbero influire sul suo funzionamento.

Verifica la presenza di operazioni simultanee

Verifica che non siano in corso contemporaneamente altre operazioni su cluster o pool di nodi. GKE in genere consente una sola operazione alla volta, il che può bloccare la scalabilità automatica.

Elenca le operazioni in corso che non si trovano nello stato DONE:

gcloud container operations list \
    --location=LOCATION \
    --filter='targetLink~"/clusters/CLUSTER_NAME" AND status!=DONE'

Se il comando restituisce operazioni, potrebbe essere in corso un'azione come l'upgrade del cluster, la creazione pool di nodi o un'altra modifica. Gli eventi di scalabilità automatica potrebbero essere bloccati fino al completamento di questa operazione.

Valutare il risultato

  • Nessuna operazione simultanea:se il comando list restituisce un elenco vuoto, il gestore della scalabilità automatica del cluster non è bloccato da alcuna operazione.

  • Operazioni simultanee trovate:

    • Interpretazione:se il comando elenca operazioni con stato RUNNING o PENDING, potrebbe essere in corso un'operazione simultanea, ad esempio un upgrade del cluster o una modifica del pool di nodi, che blocca la scalabilità automatica.

    • Risoluzione:attendi il completamento dell'operazione in corso. Puoi monitorare lo stato utilizzando un ID operazione:

      gcloud container operations wait OPERATION_ID --location LOCATION

      Sostituisci OPERATION_ID con l'ID dell'output del comando list. Al termine dell'operazione di blocco, il gestore della scalabilità automatica del cluster dovrebbe riprendere il normale funzionamento.

Esaminare la migrazione attiva

Se noti che i carichi di lavoro rimangono su nodi con priorità inferiore quando sono disponibili nodi con priorità più alta, verifica se la migrazione attiva è abilitata. Se il campo activeMigration.optimizeRulePriority è impostato su false o omesso in ComputeClass, GKE non sposterà automaticamente i carichi di lavoro sui nodi con priorità più alta quando diventano disponibili.

  1. Per controllare le tolleranze dei pod, esamina il campo spec.tolerations. Se il pod ha tolleranze che corrispondono a incompatibilità su più pool di nodi di priorità diverse, lo scheduler potrebbe posizionarlo su un nodo a priorità inferiore se è disponibile per primo.

    kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.tolerations[*]}{"\n"}'

  2. Per verificare se la migrazione attiva è abilitata, esamina il manifest ComputeClass per il campo spec.activeMigration.optimizeRulePriority.

    kubectl get computeclass CUSTOM_COMPUTECLASS_NAME -o yaml

Valutare il risultato

  • Migrazione attiva abilitata:se il campo activeMigration.optimizeRulePriority è true, GKE tenta di spostare i carichi di lavoro sui nodi con priorità più alta quando diventano disponibili.

  • Migrazione attiva disattivata o inefficace:

    • Interpretazione:se il campo activeMigration.optimizeRulePriority è false o omesso oppure se le tolleranze dei pod sono troppo ampie, i carichi di lavoro rimangono sui nodi con priorità inferiore quando sono disponibili nodi con priorità più alta. Questo approccio consente di pianificare i carichi di lavoro sui nodi con priorità inferiore che diventano disponibili per primi.

    • Risoluzione:se vuoi che i carichi di lavoro vengano spostati su nodi con priorità più alta, esegui una delle seguenti azioni:

      • Utilizza vincoli di pianificazione più specifici, come nodeAffinity, per dare la precedenza ai pool di nodi con priorità più alta.

      • Modifica il manifest ComputeClass per impostare activeMigration.optimizeRulePriority: true e applica il file YAML:

        spec:
  activeMigration:
    optimizeRulePriority: true

Assistenza

  • Se non riesci a trovare una soluzione al tuo problema nella documentazione, consulta la sezione Richiedi assistenza per ulteriore aiuto, inclusi consigli sui seguenti argomenti:

Passaggi successivi