Risolvere i problemi relativi alle TPU in GKE

Questa pagina mostra come risolvere i problemi relativi alle TPU in Google Kubernetes Engine (GKE).

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.

Quota insufficiente per soddisfare la richiesta TPU

Un errore simile a Insufficient quota to satisfy the request indica che il tuo progetto Google Cloud non dispone di una quota sufficiente per soddisfare la richiesta.

Per risolvere il problema, controlla il limite di quota e l'utilizzo corrente del progetto. Se necessario, richiedi un aumento della quota TPU.

Controllare il limite della quota e l'utilizzo corrente

Le sezioni seguenti ti aiutano ad assicurarti di avere una quota sufficiente quando utilizzi le TPU in GKE.

Per controllare il limite e l'utilizzo corrente della quota dell'API Compute Engine per le TPU, segui questi passaggi:

  1. Vai alla pagina Quote nella console Google Cloud:

    Vai a Quote

  2. Nella casella Filtro, procedi nel seguente modo:

    1. Seleziona la proprietà Servizio, inserisci API Compute Engine e premi Invio.

    2. Seleziona la proprietà Tipo e scegli Quota.

    3. Seleziona la proprietà Nome e inserisci il nome della quota in base alla versione TPU e Ad esempio, se prevedi di creare nodi TPU v5e on demand, inserisci TPU v5 Lite PodSlice chips.

      Versione TPU Nome della quota per le istanze on demand Nome della quota per le istanze Spot2
      TPU v3 TPU v3 Device chips Preemptible TPU v3 Device chips
      TPU v3 TPU v3 PodSlice chips Preemptible TPU v3 PodSlice chips
      TPU v4 TPU v4 PodSlice chips Preemptible TPU v4 PodSlice chips
      TPU v5e TPU v5 Lite Device chips Preemptible TPU v5 Lite Device chips
      TPU v5e TPU v5 Lite PodSlice chips Preemptible TPU v5 Lite PodSlice chips
      TPU v5p TPU v5p chips Preemptible TPU v5p chips
      TPU v6e TPU v6e Slice chips Preemptible TPU v6e Lite PodSlice chips

    4. Seleziona la proprietà Dimensioni (ad es. località) e inserisci region: seguito dal nome della regione in cui prevedi di creare le TPU in GKE. Ad esempio, inserisci region:us-west4 se prevedi di creare nodi di slice TPU nella zona us-west4-a. La quota TPU è regionale, pertanto tutte le zone all'interno della stessa regione consumano la stessa quota TPU.

Se nessuna quota corrisponde al filtro inserito, significa che al progetto non è stata assegnata alcuna quota specificata per la regione di cui hai bisogno e devi richiedere un aumento della quota TPU.

Quando viene creata una prenotazione TPU, sia il limite sia i valori di utilizzo corrente per la quota corrispondente aumentano in base al numero di chip nella prenotazione TPU. Ad esempio, quando viene creata una prenotazione per 16 chip TPU v5e, entrambi i valori Limite e Utilizzo corrente per la quota TPU v5 Lite PodSlice chips nella regione pertinente aumentano di 16.

Quote per risorse GKE aggiuntive

Potresti dover aumentare le seguenti quote relative a GKE nelle regioni in cui GKE crea le tue risorse.

  • Quota SSD (GB) di Persistent Disk: il disco di avvio di ogni nodo Kubernetes richiede 100 GB per impostazione predefinita. Pertanto, questa quota deve essere impostata su un valore almeno uguale al prodotto del numero massimo di nodi GKE che prevedi di creare e 100 GB (nodi * 100 GB).
  • Quota indirizzi IP in uso: ogni nodo Kubernetes utilizza un indirizzo IP. Pertanto, questa quota deve essere impostata almeno sul numero massimo di nodi GKE che prevedi di creare.
  • Assicurati che max-pods-per-node sia in linea con l'intervallo della subnet: ogni nodo Kubernetes utilizza intervalli IP secondari per i pod. Ad esempio, max-pods-per-node di 32 richiede 64 indirizzi IP, che si traducono in una subnet /26 per nodo. Tieni presente che questo intervallo non deve essere condiviso con nessun altro cluster. Per evitare di esaurire l'intervallo di indirizzi IP, utilizza il flag --max-pods-per-node per limitare il numero di pod che è consentito pianificare su un nodo. La quota per max-pods-per-node deve essere impostata su un valore almeno pari al numero massimo di nodi GKE che prevedi di creare.

Per richiedere un aumento della quota, vedi Richiedere una quota superiore.

Errore durante l'attivazione del provisioning automatico dei nodi in un pool di nodi di slice TPU

Il seguente errore si verifica quando attivi il provisioning automatico dei nodi in un cluster GKE che non supporta le TPU.

Il messaggio di errore è simile al seguente:

ERROR: (gcloud.container.clusters.create) ResponseError: code=400,
  message=Invalid resource: tpu-v4-podslice.

Per risolvere il problema, esegui l'upgrade del cluster GKE alla versione 1.27.6 o successiva.

GKE non esegue automaticamente il provisioning dei nodi della sezione TPU

Le sezioni seguenti descrivono i casi in cui GKE non esegue il provisioning automatico dei nodi dei segmenti TPU e come risolverli.

Configurazione errata del limite

GKE non esegue automaticamente il provisioning dei nodi dei sezioni TPU se i limiti di provisioning automatico che hai definito per un cluster sono troppo bassi. In questi scenari potresti osservare i seguenti errori:

  • Se esiste un pool di nodi di sezioni TPU, ma GKE non riesce ad aumentare le dimensioni dei nodi a causa della violazione dei limiti di risorse, quando esegui il comando kubectl get events potresti visualizzare il seguente messaggio di errore:

    11s Normal NotTriggerScaleUp pod/tpu-workload-65b69f6c95-ccxwz pod didn't
trigger scale-up: 1 node(s) didn't match Pod's node affinity/selector, 1 max
cluster cpu, memory limit reached

    Inoltre, in questo scenario, nella console Google Cloud puoi visualizzare messaggi di avviso simili al seguente:

    "Your cluster has one or more unschedulable Pods"

  • Quando GKE tenta di eseguire il provisioning automatico di un pool di nodi di sezioni TPU che supera i limiti delle risorse, nei log di visibilità del cluster autoscaler viene visualizzato il seguente messaggio di errore:

    messageId: "no.scale.up.nap.pod.zonal.resources.exceeded"

    Inoltre, in questo scenario, nella console Google Cloud puoi visualizzare messaggi di avviso simili al seguente:

    "Can't scale up because node auto-provisioning can't provision a node pool for
the Pod if it would exceed resource limits"

Per risolvere questi problemi, aumenta il numero massimo di chip TPU, core CPU e memoria nel cluster.

Per completare questi passaggi:

  1. Calcola i requisiti delle risorse per un determinato tipo e numero di macchine TPU. Tieni presente che devi aggiungere risorse per i pool di nodi di slice non TPU, come i carichi di lavoro di sistema.

  2. Ottieni una descrizione delle TPU, delle CPU e della memoria disponibili per un tipo di macchina e una zona specifici. Utilizza gcloud CLI:

    gcloud compute machine-types describe MACHINE_TYPE \
    --zone COMPUTE_ZONE

    Sostituisci quanto segue:

    • MACHINE_TYPE: il tipo di macchina da cercare.
    • COMPUTE_ZONE: il nome della zona di calcolo.

    L'output include una riga di descrizione simile alla seguente:

      description: 240 vCPUs, 407 GB RAM, 4 Google TPUs
  ```

  3. Calcola il numero totale di CPU e memoria moltiplicando queste quantità per il numero di nodi richiesto. Ad esempio, il tipo di macchina ct4p-hightpu-4t utilizza 240 core CPU e 407 GB di RAM con 4 chip TPU. Supponendo che tu abbia bisogno di 20 chip TPU, che corrispondono a cinque nodi, devi definire i seguenti valori:

    • --max-accelerator=type=tpu-v4-podslice,count=20.
    • CPU = 1200 (240 x 5)
    • memory = 2035 (407 volte 5)

    Devi definire i limiti con un certo margine per adattarli ai nodi di slice non TPU, come i carichi di lavoro di sistema.

  4. Aggiorna i limiti del cluster:

    gcloud container clusters update CLUSTER_NAME \
    --max-accelerator type=TPU_ACCELERATOR \
    count=MAXIMUM_ACCELERATOR \
    --max-cpu=MAXIMUM_CPU \
    --max-memory=MAXIMUM_MEMORY

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster.
    • TPU_ACCELERATOR: il nome dell'acceleratore TPU.
    • MAXIMUM_ACCELERATOR: il numero massimo di chip TPU nel cluster.
    • MAXIMUM_CPU: il numero massimo di core nel cluster.
    • MAXIMUM_MEMORY: il numero massimo di gigabyte di memoria nel cluster.

Non tutte le istanze sono in esecuzione

ERROR: nodes cannot be created due to lack of capacity. The missing nodes
will be created asynchronously once capacity is available. You can either
wait for the nodes to be up, or delete the node pool and try re-creating it
again later.

Questo errore può verificarsi quando l'operazione GKE ha esaurito il tempo di attesa o la richiesta non può essere completata e messa in coda per il provisioning di pool di nodi TPU a host singolo o multi-host. Per ridurre i problemi di capacità, puoi utilizzare le reservations o prendere in considerazione le VM spot.

Configurazione errata del workload

Questo errore si verifica a causa di una configurazione errata del workload. Di seguito sono riportate alcune delle cause più comuni dell'errore:

  • Le etichette cloud.google.com/gke-tpu-accelerator e cloud.google.com/gke-tpu-topology non sono corrette o mancano nella specifica del pod. GKE non eseguirà il provisioning dei node pool di sezioni TPU e il provisioning automatico dei nodi non potrà eseguire lo scale up del cluster.
  • La specifica del pod non specifica google.com/tpu nei requisiti delle risorse.

Per risolvere il problema, esegui una delle seguenti operazioni:

  1. Verifica che non siano presenti etichette non supportate nel selettore dei nodi del carico di lavoro. Ad esempio, un selettore di nodi per l'etichetta cloud.google.com/gke-nodepool impedirà a GKE di creare node pool aggiuntivi per i tuoi pod.
  2. Assicurati che le specifiche del modello di pod in cui viene eseguito il tuo workload TPU includano i seguenti valori:
    • cloud.google.com/gke-tpu-accelerator e cloud.google.com/gke-tpu-topology nel nodeSelector.
    • google.com/tpu nella richiesta.

Per scoprire come eseguire il deployment dei carichi di lavoro TPU in GKE, consulta Eseguire un carico di lavoro che mostra il numero di chip TPU disponibili in un node pool di sezioni TPU.

Errori di pianificazione durante il deployment di pod che utilizzano TPU in GKE

Il seguente problema si verifica quando GKE non riesce a pianificare i pod che richiedono TPU sui nodi della sezione TPU. Ad esempio, questo potrebbe verificarsi se alcuni slice non TPU erano già pianificati sui nodi TPU.

Il messaggio di errore, emesso come evento FailedScheduling sul pod, è simile al seguente:

Cannot schedule pods: Preemption is not helpful for scheduling.

Error message: 0/2 nodes are available: 2 node(s) had untolerated taint
{google.com/tpu: present}. preemption: 0/2 nodes are available: 2 Preemption is
not helpful for scheduling

Per risolvere il problema:

Verifica di avere almeno un pool di nodi CPU nel cluster in modo che i pod critici per il sistema possano essere eseguiti nei nodi non TPU. Per saperne di più, consulta Eseguire il deployment di un pod in un pool di nodi specifico.

Risolvere i problemi comuni relativi ai set di job in GKE

Per i problemi comuni di JobSet e suggerimenti per la risoluzione dei problemi, consulta la pagina Risoluzione dei problemi di JobSet. Questa pagina illustra i problemi comuni, come l'errore "Webhook non disponibile", i job secondari o i pod che non vengono creati e il problema di ripresa dei carichi di lavoro con preemption utilizzando JobSet e Kueue.

Inizializzazione della TPU non riuscita

Il seguente problema si verifica quando GKE non riesce a eseguire il provisioning di nuovi workload TPU a causa della mancanza dell'autorizzazione per accedere ai dispositivi TPU.

Il messaggio di errore è simile al seguente:

TPU platform initialization failed: FAILED_PRECONDITION: Couldn't mmap: Resource
temporarily unavailable.; Unable to create Node RegisterInterface for node 0,
config: device_path: "/dev/accel0" mode: KERNEL debug_data_directory: ""
dump_anomalies_only: true crash_in_debug_dump: false allow_core_dump: true;
could not create driver instance

Per risolvere il problema, assicurati di eseguire il contenitore TPU in modalità privilegiata o di aumentare il valore ulimit all'interno del contenitore.

Blocco della pianificazione

La pianificazione di due o più job potrebbe non riuscire in caso di deadlock. Ad esempio, nello scenario in cui si verificano tutte le seguenti condizioni:

  • Hai due job (job A e job B) con regole di affinità dei pod. GKE pianifica le sezioni TPU per entrambi i job con una topologia TPU di v4-32.
  • Nel cluster sono presenti due sezioni TPU v4-32.
  • Il tuo cluster ha una capacità sufficiente per pianificare entrambi i job e, in teoria, ogni job può essere pianificato rapidamente su ogni slice TPU.
  • Lo scheduler Kubernetes pianifica un pod dal job A su un livello, quindi pianifica un pod dal job B sullo stesso livello.

In questo caso, date le regole di affinità dei pod per il job A, lo scheduler tenta di pianificare tutti i pod rimanenti per il job A e per il job B su un singolo slice TPU ciascuno. Di conseguenza, GKE non potrà pianificare completamente il job A o il job B. Di conseguenza, lo stato di entrambi i job rimarrà In attesa.

Per risolvere il problema, utilizza l'anti-affinità dei pod con cloud.google.com/gke-nodepool come topologyKey, come mostrato nell'esempio seguente:

apiVersion: batch/v1
kind: Job
metadata:
 name: pi
spec:
 parallelism: 2
 template:
   metadata:
     labels:
       job: pi
   spec:
     affinity:
       podAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: job
               operator: In
               values:
               - pi
           topologyKey: cloud.google.com/gke-nodepool
       podAntiAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: job
               operator: NotIn
               values:
               - pi
           topologyKey: cloud.google.com/gke-nodepool
           namespaceSelector:
             matchExpressions:
             - key: kubernetes.io/metadata.name
               operator: NotIn
               values:
               - kube-system
     containers:
     - name: pi
       image: perl:5.34.0
       command: ["sleep",  "60"]
     restartPolicy: Never
 backoffLimit: 4

Autorizzazione negata durante la creazione del cluster in us-central2

Se stai tentando di creare un cluster in us-central2 (l'unica regione in cui è disponibile TPU v4), potresti visualizzare un messaggio di errore simile al seguente:

ERROR: (gcloud.container.clusters.create) ResponseError: code=403,
message=Permission denied on 'locations/us-central2' (or it may not exist).

Questo errore si verifica perché la regione us-central2 è una regione privata.

Per risolvere il problema, apri una richiesta di assistenza o contatta il team dell'account per chiedere di rendere visibile us-central2 nel progetto Google Cloud.

Quota insufficiente durante la creazione del pool di nodi TPU in us-central2

Se stai tentando di creare un pool di nodi di sezioni TPU in us-central2 (l'unica regione in cui è disponibile TPU v4), potrebbe essere necessario aumentare le seguenti quote relative a GKE la prima volta che crei i node pool TPU v4:

  • Quota SSD (GB) di Persistent Disk in us-central2: per impostazione predefinita, il disco di avvio di ogni nodo Kubernetes richiede 100 GB. Pertanto, questa quota deve essere impostata almeno su un valore pari al prodotto del numero massimo di nodi GKE che prevedi di creare in us-central2 e 100 GB (maximum_nodes x 100 GB).
  • Quota di indirizzi IP in uso in us-central2: ogni nodo Kubernetes consuma un indirizzo IP. Pertanto, questa quota deve essere impostata su un valore almeno pari al numero massimo di nodi GKE che prevedi di creare in us-central2.

Subnet mancante durante la creazione del cluster GKE

Se stai tentando di creare un cluster in us-central2 (l'unica regione in cui è disponibile TPU v4), potresti visualizzare un messaggio di errore simile al seguente:

ERROR: (gcloud.container.clusters.create) ResponseError: code=404,
message=Not found: project <PROJECT> does not have an auto-mode subnetwork
for network "default" in region <REGION>.

Nella rete VPC è necessaria una subnet per fornire connettività ai tuoi nodi GKE. Tuttavia, in alcune regioni come us-central2, potrebbe non essere creata una subnet predefinita, anche se utilizzi la rete VPC predefinita in modalità automatica (per la creazione di subnet).

Per risolvere il problema, assicurati di aver creato una sottorete personalizzata nella regione prima di creare il cluster GKE. Questa subnet non deve sovrapporsi ad altre subnet create in altre regioni nella stessa rete VPC.

Visualizza i log di TPU GKE

Per visualizzare tutti i log relativi a TPU per un caricamento di lavoro specifico, Cloud Logging offre una posizione centralizzata per eseguire query su questi log quando il logging del sistema e del carico di lavoro di GKE è abilitato. In Cloud Logging, i log sono organizzati in voci di log e ogni singola voce di log ha un formato strutturato. Di seguito è riportato un esempio di voce di log di un job di addestramento TPU.

{
  insertId: "gvqk7r5qc5hvogif"
  labels: {
  compute.googleapis.com/resource_name: "gke-tpu-9243ec28-wwf5"
  k8s-pod/batch_kubernetes_io/controller-uid: "443a3128-64f3-4f48-a4d3-69199f82b090"
  k8s-pod/batch_kubernetes_io/job-name: "mnist-training-job"
  k8s-pod/controller-uid: "443a3128-64f3-4f48-a4d3-69199f82b090"
  k8s-pod/job-name: "mnist-training-job"
}
logName: "projects/gke-tpu-demo-project/logs/stdout"
receiveTimestamp: "2024-06-26T05:52:39.652122589Z"
resource: {
  labels: {
    cluster_name: "tpu-test"
    container_name: "tensorflow"
    location: "us-central2-b"
    namespace_name: "default"
    pod_name: "mnist-training-job-l74l8"
    project_id: "gke-tpu-demo-project"
}
  type: "k8s_container"
}
severity: "INFO"
textPayload: "
  1/938 [..............................] - ETA: 13:36 - loss: 2.3238 - accuracy: 0.0469
  6/938 [..............................] - ETA: 9s - loss: 2.1227 - accuracy: 0.2995   
 13/938 [..............................] - ETA: 8s - loss: 1.7952 - accuracy: 0.4760
 20/938 [..............................] - ETA: 7s - loss: 1.5536 - accuracy: 0.5539
 27/938 [..............................] - ETA: 7s - loss: 1.3590 - accuracy: 0.6071
 36/938 [>.............................] - ETA: 6s - loss: 1.1622 - accuracy: 0.6606
 44/938 [>.............................] - ETA: 6s - loss: 1.0395 - accuracy: 0.6935
 51/938 [>.............................] - ETA: 6s - loss: 0.9590 - accuracy: 0.7160
……
937/938 [============================>.] - ETA: 0s - loss: 0.2184 - accuracy: 0.9349"
timestamp: "2024-06-26T05:52:38.962950115Z"
}

Ogni voce di log dei nodi del segmento TPU ha l'etichetta compute.googleapis.com/resource_name con il valore impostato come nome del nodo. Se vuoi visualizzare i log di un determinato nodo e ne conosci il nome, puoi filtrare i log in base a quel nodo nella query. Ad esempio, la seguente query mostra i log del nodo TPU gke-tpu-9243ec28-wwf5:

resource.type="k8s_container"
labels."compute.googleapis.com/resource_name" = "gke-tpu-9243ec28-wwf5"

GKE aggiunge le etichette cloud.google.com/gke-tpu-accelerator e cloud.google.com/gke-tpu-topology a tutti i nodi contenenti TPU. Pertanto, se non hai la certezza del nome del nodo o vuoi elencare tutti i nodi del segmento TPU, puoi eseguire il seguente comando:

kubectl get nodes -l cloud.google.com/gke-tpu-accelerator

Esempio di output:

NAME                    STATUS   ROLES    AGE     VERSION
gke-tpu-9243ec28-f2f1   Ready    <none>   25m     v1.30.1-gke.1156000
gke-tpu-9243ec28-wwf5   Ready    <none>   7d22h   v1.30.1-gke.1156000

Puoi applicare ulteriori filtri in base alle etichette dei nodi e ai relativi valori. Ad esempio, il seguente comando elenca il nodo TPU con un tipo e una topology specifici:

kubectl get nodes -l cloud.google.com/gke-tpu-accelerator=tpu-v5-lite-podslice,cloud.google.com/gke-tpu-topology=1x1

Per visualizzare tutti i log nei nodi della sezione TPU, puoi utilizzare la query che associa l'etichetta al suffisso del nodo della sezione TPU. Ad esempio, utilizza la seguente query:

resource.type="k8s_container"
labels."compute.googleapis.com/resource_name" =~ "gke-tpu-9243ec28.*"
log_id("stdout")

Per visualizzare i log associati a un determinato carico di lavoro TPU utilizzando un job Kubernetes, puoi filtrare i log utilizzando l'etichetta batch.kubernetes.io/job-name. Ad esempio, per il job mnist-training-job, puoi eseguire la seguente query per i log STDOUT:

resource.type="k8s_container"
labels."k8s-pod/batch_kubernetes_io/job-name" = "mnist-training-job"
log_id("stdout")

Per visualizzare i log di un carico di lavoro TPU utilizzando un JobSet Kubernetes, puoi filtrare i log utilizzando l'etichetta k8s-pod/jobset_sigs_k8s_io/jobset-name. Ad esempio:

resource.type="k8s_container"
labels."k8s-pod/jobset_sigs_k8s_io/jobset-name"="multislice-job"

Per visualizzare ulteriori dettagli, puoi filtrare in base alle altre etichette dei carichi di lavoro. Ad esempio, per visualizzare i log di un workload multislice dal worker 0 e dalla fetta 1, puoi filtrare in base alle etichette job-complete-index e job-index:

​​resource.type="k8s_container"
labels."k8s-pod/jobset_sigs_k8s_io/jobset-name"="multislice-job"
labels."k8s-pod/batch_kubernetes_io/job-completion-index"="0"
labels."k8s-pod/jobset_sigs_k8s_io/job-index"="1"

Puoi anche filtrare utilizzando il pattern del nome del pod:

resource.labels.pod_name:<jobSetName>-<replicateJobName>-<job-index>-<worker-index>

Ad esempio, nella seguente query jobSetName è il job multislice e replicateJobName è la frazione. Sia job-index che worker-index sono 0:

resource.type="k8s_container"
labels."k8s-pod/jobset_sigs_k8s_io/jobset-name"="multislice-job"
resource.labels.pod_name:"multislice-job-slice-0-0"

Per altri carichi di lavoro TPU, ad esempio un singolo carico di lavoro del pod GKE, puoi filtrare i log in base ai nomi dei pod. Ad esempio:

resource.type="k8s_container"
resource.labels.pod_name="tpu-job-jax-demo"

Se vuoi verificare se il plug-in del dispositivo TPU è in esecuzione correttamente, puoi utilizzare la seguente query per controllare i relativi log del contenitore:

resource.type="k8s_container"
labels.k8s-pod/k8s-app="tpu-device-plugin"
resource.labels.namespace_name="kube-system"

Esegui la seguente query per controllare gli eventi correlati:

jsonPayload.involvedObject.name=~"tpu-device-plugin.*"
log_id("events")

Per tutte le query, puoi aggiungere filtri aggiuntivi, ad esempio il nome del cluster, la posizione e l'ID progetto. Puoi anche combinare le condizioni per restringere i risultati. Ad esempio:

resource.type="k8s_container" AND
resource.labels.project_id="gke-tpu-demo-project" AND
resource.labels.location="us-west1" AND
resource.labels.cluster_name="tpu-demo" AND
resource.labels.namespace_name="default" AND
labels."compute.googleapis.com/resource_name" =~ "gke-tpu-9243ec28.*" AND
labels."k8s-pod/batch_kubernetes_io/job-name" = "mnist-training-job" AND
log_id("stdout")

L'operatore AND è facoltativo tra i confronti e può essere omesso. Per ulteriori informazioni sul linguaggio delle query, puoi leggere la specifica del linguaggio delle query di Logging. Per altri esempi di query, puoi anche leggere le query dei log relative a Kubernetes.

Se preferisci utilizzare SQL con Log Analytics, puoi trovare esempi di query in Query SQL con Log Analytics. In alternativa, puoi anche eseguire le query utilizzando Google Cloud CLI anziché Esplora log. Ad esempio:

gcloud logging read 'resource.type="k8s_container" labels."compute.googleapis.com/resource_name" =~ "gke-tpu-9243ec28.*" log_id("stdout")' --limit 10 --format json

Passaggi successivi

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.