Fehlerbehebung bei TPUs in GKE

Auf dieser Seite wird beschrieben, wie Sie Probleme im Zusammenhang mit TPUs in Google Kubernetes Engine (GKE) beheben.

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.

Unzureichendes Kontingent, um die TPU-Anfrage zu erfüllen

Ein Fehler wie Insufficient quota to satisfy the request gibt an, dass Ihr Google Cloud-Projekt kein ausreichendes Kontingent hat, um die Anfrage zu erfüllen.

Um dieses Problem zu beheben, prüfen Sie das Kontingentlimit Ihres Projekts und die aktuelle Nutzung. Fordern Sie bei Bedarf eine Erhöhung Ihres TPU-Kontingents an.

Kontingentlimit und aktuelle Nutzung prüfen

Führen Sie die folgenden Schritte aus, um das Limit und die aktuelle Nutzung Ihres Compute Engine API-Kontingents für TPUs zu prüfen:

  1. Rufen Sie in der Google Cloud Console die Seite Kontingente auf.

    Kontingente aufrufen

  2. Gehen Sie im Feld Filter folgendermaßen vor:

    1. Wählen Sie das Attribut Dienst aus, geben Sie Compute Engine API ein und drücken Sie die Eingabetaste.

    2. Wählen Sie das Attribut Typ und dann Kontingent aus.

    3. Wählen Sie das Attribut Dimensionen (z.B. Standorte) aus und geben Sie region: gefolgt vom Namen der Region ein, in der Sie TPUs in GKE erstellen möchten. Geben Sie beispielsweise region:us-west4 ein, wenn Sie TPU-Slice-Knoten in der Zone us-west4-a erstellen möchten. Das TPU-Kontingent ist regional, d. h. alle Zonen innerhalb derselben Region nutzen dasselbe TPU-Kontingent.

Wenn keine Kontingente vorhanden sind, die Sie eingegeben haben, wurde dem Projekt keines der angegebenen Kontingente für die gewünschte Region zugewiesen und Sie müssen eine TPU-Kontingenterhöhung anfordern.

Fehler beim Aktivieren der automatischen Knotenbereitstellung in einem TPU-Slice-Knotenpool

Der folgende Fehler tritt auf, wenn Sie die automatische Knotenbereitstellung in einem GKE-Cluster aktivieren, der keine TPUs unterstützt.

Die Fehlermeldung sieht etwa so aus:

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

Aktualisieren Sie Ihren GKE-Cluster auf Version 1.27.6 oder höher, um dieses Problem zu beheben.

GKE stellt TPU-Slice-Knoten nicht automatisch bereit

In den folgenden Abschnitten werden die Fälle beschrieben, in denen GKE TPU-Slice-Knoten nicht automatisch bereitstellt, und wie Sie diese beheben.

Fehlkonfiguration einschränken

GKE stellt TPU-Slice-Knoten nicht automatisch bereit, wenn die von Ihnen für einen Cluster definierten Limits für die automatische Bereitstellung zu niedrig sind. In solchen Szenarien können Sie die folgenden Fehler beobachten:

  • Wenn ein TPU-Slice-Knotenpool vorhanden ist, GKE die Knoten jedoch aufgrund von Verstößen von Ressourcenlimits nicht hochskalieren kann, wird beim Ausführen des Befehls kubectl get events die folgende Fehlermeldung angezeigt:

    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

    Außerdem werden in diesem Szenario in der Google Cloud Console Warnmeldungen wie die folgenden angezeigt:

    "Your cluster has one or more unschedulable Pods"

  • Wenn GKE versucht, einen TPU-Slice-Knotenpool automatisch bereitzustellen, der die Ressourcenlimits überschreitet, wird in den Logs zur Cluster-Autoscaling-Sichtbarkeit folgende Fehlermeldung angezeigt:

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

    Außerdem werden in diesem Szenario in der Google Cloud Console Warnmeldungen wie die folgenden angezeigt:

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

Erhöhen Sie die maximale Anzahl von TPU-Chips, CPU-Kernen, und Arbeitsspeicher im Cluster.

So führen Sie diese Schritte aus:

  1. Berechnen der Ressourcenanforderungen für einen bestimmten TPU-Maschinentyp und eine bestimmte Anzahl. Beachten Sie, dass Sie Ressourcen für Nicht-TPU-Slice-Knotenpools wie Systemarbeitsbelastungen hinzufügen müssen.

  2. Rufen Sie eine Beschreibung der verfügbaren TPU, CPU und des verfügbaren Arbeitsspeichers für einen bestimmten Maschinentyp und eine bestimmte Zone ab. gcloud CLI verwenden:

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

    Ersetzen Sie Folgendes:

    • MACHINE_TYPE: Der zu durchsuchende Maschinentyp.
    • COMPUTE_ZONE: Der Name der Computing-Zone.

    Die Ausgabe enthält eine Textzeile, die in etwa so aussieht:

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

  3. Berechnen Sie die Gesamtzahl von CPU und Arbeitsspeicher, indem Sie diese Beträge mit der erforderlichen Knotenanzahl multiplizieren. Der Maschinentyp ct4p-hightpu-4t verwendet beispielsweise 240 CPU-Kerne und 407 GB RAM mit 4 TPU-Chips. Wenn Sie 20 TPU-Chips benötigen, die fünf Knoten entsprechen, müssen Sie die folgenden Werte definieren:

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

    Sie sollten die Limits mit einem gewissen Spielraum definieren, um Nicht-Slice-TPU-Knoten wie Systemarbeitslasten zu berücksichtigen.

  4. Aktualisieren Sie die Clusterlimits:

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

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: Der Name des Clusters.
    • TPU_ACCELERATOR: Der Name des TPU-Beschleunigers
    • MAXIMUM_ACCELERATOR: Die maximale Anzahl von TPU-Chips im Cluster
    • MAXIMUM_CPU: Die maximale Anzahl der Kerne im Cluster
    • MAXIMUM_MEMORY: Die maximale Anzahl von Gigabyte Arbeitsspeicher im Cluster

Nicht alle Instanzen werden ausgeführt

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.

Dieser Fehler kann auftreten, wenn der GKE-Vorgang abgelaufen ist oder die Anfrage nicht erfüllt werden kann und sich in der Warteschlange für die Bereitstellung von TPU-Knotenpools mit einem oder mehreren Hosts befindet. Sie können Reservierungen verwenden oder Spot-VMs in Betracht ziehen, um Kapazitätsprobleme zu minimieren.

Fehlkonfiguration der Arbeitslast

Dieser Fehler tritt aufgrund einer falschen Konfiguration der Arbeitslast auf. Im Folgenden finden Sie einige der häufigsten Ursachen dafür:

  • Die Labels cloud.google.com/gke-tpu-accelerator und cloud.google.com/gke-tpu-topology sind falsch oder fehlen in der Pod-Spezifikation. GKE kann keine TPU-Slice-Knotenpools bereitstellen und die automatische Knotenbereitstellung kann den Cluster nicht hochskalieren.
  • Die Pod-Spezifikation gibt google.com/tpu nicht in den Ressourcenanforderungen an.

Führen Sie einen der folgenden Schritte aus, um das Problem zu lösen:

  1. Prüfen Sie, ob in Ihrer Arbeitslastknotenauswahl keine nicht unterstützten Labels vorhanden sind. Ein Knotenselektor für das Label cloud.google.com/gke-nodepool verhindert, dass GKE zusätzliche Knotenpools für Ihre Pods erstellt.
  2. Achten Sie darauf, dass die Spezifikationen der Pod-Vorlage, in denen Ihre TPU-Arbeitslast ausgeführt wird, folgende Werte enthalten:
    • cloud.google.com/gke-tpu-accelerator und cloud.google.com/gke-tpu-topology Labels in nodeSelector.
    • google.com/tpu in seiner Anfrage.

Informationen zum Bereitstellen von TPU-Arbeitslasten in GKE finden Sie unter Arbeitslast ausführen, die die Anzahl der verfügbaren TPU-Chips in einem TPU-Slice-Knotenpool anzeigt.

Planungsfehler bei der Bereitstellung von Pods, die TPUs in GKE nutzen

Das folgende Problem tritt auf, wenn GKE keine Pods planen kann, die TPUs auf TPU-Slice-Knoten anfordern. Dies kann beispielsweise der Fall sein, wenn einige Nicht-TPU-Pods bereits auf TPU-Slice-Knoten geplant wurden.

Die Fehlermeldung, die als FailedScheduling-Ereignis auf dem Pod ausgegeben wird, sieht in etwa so aus:

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

So beheben Sie das Problem:

Prüfen Sie, ob sich in Ihrem Cluster mindestens ein CPU-Knotenpool befindet, damit die systemkritischen Pods auf den Nicht-TPU-Knoten ausgeführt werden können. Weitere Informationen finden Sie unter Pod in einem bestimmten Knotenpool bereitstellen.

Häufige Probleme mit JobSets in GKE beheben

Häufige Probleme mit JobSet und Vorschläge zur Fehlerbehebung finden Sie auf der Seite JobSet-Fehlerbehebung. Auf dieser Seite werden häufige Probleme behandelt, wie der Fehler „Webhook nicht verfügbar“, untergeordnete Jobs oder nicht erstellte Pods und die Wiederaufnahme von Arbeitslasten, die mithilfe von JobSet und Kueue unterbrochen wurden.

TPU-Initialisierung fehlgeschlagen

Das folgende Problem tritt auf, wenn die GKE keine neuen TPU-Arbeitslasten bereitstellen kann, da sie keine Berechtigung für den Zugriff auf TPU-Geräte hat.

Die Fehlermeldung sieht etwa so aus:

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

Zur Behebung dieses Problems müssen Sie entweder den TPU-Container im privilegierten Modus ausführen oder ulimit im Container erhöhen.

Planungs-Deadlock

Die Planung von zwei oder mehr Jobs kann aufgrund eines Deadlocks fehlschlagen. Die kann zum Beispiel vorkommen, wenn alle folgenden Bedingungen zutreffen:

  • Sie haben zwei Jobs (Job A und Job B) mit Pod-Affinitätsregeln. GKE plant die TPU-Slices für beide Jobs mit der TPU-Topologie v4-32.
  • Der Cluster enthält zwei v4-32-TPU-Slices.
  • Ihr Cluster verfügt über genügend Kapazität, um beide Jobs zu planen, wobei theoretisch jeder Job schnell auf jedem TPU-Slice geplant werden kann.
  • Der Kubernetes-Planer plant einen Pod aus Job A in einem Slice und plant dann einen Pod aus Job B im selben Slice.

Aufgrund der Pod-Affinitätsregeln für Job A versucht der Planer in diesem Fall, alle verbleibenden Pods für Job A und Job B in einem einzelnen TPU-Slice zu planen. Daher kann GKE weder Job A noch Job B vollständig planen. Daher bleibt der Status beider Jobs bei „Ausstehend“.

Verwenden Sie zur Behebung dieses Problems die Pod-Anti-Affinität mit cloud.google.com/gke-nodepool als topologyKey, wie im folgenden Beispiel gezeigt:

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

Berechtigung während der Clustererstellung in us-central2 verweigert

Wenn Sie einen Cluster in us-central2 erstellen (die einzige Region, in der TPU v4 verfügbar ist), kann eine Fehlermeldung ähnlich der folgenden angezeigt werden:

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

Dieser Fehler liegt daran, dass die Region us-central2 eine private Region ist.

Um dieses Problem zu beheben, reichen Sie eine Supportanfrage ein oder wenden Sie sich an Ihr Account-Management-Team, damit sie us-central2 in Ihrem Google Cloud-Projekt sichtbar machen.

Unzureichendes Kontingent beim Erstellen des TPU-Knotenpools in us-central2

Wenn Sie versuchen, einen TPU-Slice-Knotenpool in us-central2 zu erstellen (die einzige Region, in der TPU v4 verfügbar ist), müssen Sie möglicherweise die folgenden GKE-bezogenen Kontingente erhöhen, wenn Sie TPU v4-Knotenpools erstellen:

  • Kontingent für Peresistent Disk SSD (GB) in us-central2: Das Bootlaufwerk jedes Kubernetes-Knotens benötigt standardmäßig 100 GB. Daher sollte dieses Kontingent mindestens so hoch wie das Produkt aus der maximalen Anzahl der GKE-Knoten, die Sie voraussichtlich in us-central2 erstellen werden, und 100 GB (maximum_nodes × 100 GB) sein.
  • Kontingent für genutzte IP-Adressen in us-central2: Jeder Kubernetes-Knoten verbraucht nur eine IP-Adresse. Daher sollte dieses Kontingent mindestens so hoch sein wie die maximale Anzahl von GKE-Knoten, die Sie voraussichtlich in us-central2 erstellen werden.

Fehlendes Subnetz während der GKE-Clustererstellung

Wenn Sie einen Cluster in us-central2 erstellen (die einzige Region, in der TPU v4 verfügbar ist), kann eine Fehlermeldung ähnlich der folgenden angezeigt werden:

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

In Ihrem VPC-Netzwerk ist ein Subnetz erforderlich, um eine Verbindung zu Ihren GKE-Knoten herzustellen. In bestimmten Regionen wie us-central2 wird jedoch möglicherweise kein Standardsubnetz erstellt, auch wenn Sie das Standard-VPC-Netzwerk im automatischen Modus (für die Subnetzerstellung) verwenden.

Um dieses Problem zu beheben, vergewissern Sie sich, dass Sie ein benutzerdefiniertes Subnetz in der Region erstellen, bevor Sie Ihr GKE-Cluster erstellen. Dieses Subnetz darf sich nicht mit anderen Subnetzen überschneiden, die in anderen Regionen desselben VPC-Netzwerks erstellt wurden.

GKE-TPU-Logs aufrufen

Zur Anzeige aller TPU-bezogenen Logs für eine bestimmte Arbeitslast bietet Cloud Logging einen zentralen Speicherort zum Abfragen dieser Logs, wenn das GKE-System- und Arbeitslast-Logging aktiviert ist. In Cloud Logging werden Logs in Logeinträgen organisiert. Jeder einzelne Logeintrag hat ein strukturiertes Format. Das folgende Beispiel zeigt einen Logeintrag eines TPU-Trainingsjobs.

{
  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"
}

Jeder Logeintrag von den TPU-Slice-Knoten hat das Label compute.googleapis.com/resource_name, wobei der Wert als Knotenname festgelegt ist. Wenn Sie die Logs eines bestimmten Knotens aufrufen möchten und den Knotennamen kennen, können Sie die Logs in Ihrer Abfrage nach diesem Knoten filtern. Die folgende Abfrage zeigt beispielsweise die Logs des TPU-Knotens gke-tpu-9243ec28-wwf5 an:

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

GKE hängt die Labels cloud.google.com/gke-tpu-accelerator und cloud.google.com/gke-tpu-topology an alle Knoten an, die TPUs enthalten. Wenn Sie sich nicht sicher sind, welchen Knotennamen Sie verwenden sollen, oder alle TPU-Slice-knoten auflisten möchten, können Sie den folgenden Befehl ausführen:

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

Beispielausgabe:

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

Sie können anhand der Knotenlabels und ihrer Werte weitere Filter anwenden. Mit dem folgenden Befehl wird beispielsweise der TPU-Knoten mit einem bestimmten Typ und einer bestimmten Topologie aufgelistet:

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

Um alle Logs über die TPU-Slice-Knoten hinweg anzuzeigen, können Sie die Abfrage verwenden, die das Label dem Suffix des TPU-Slice-Knotens zuordnet. Verwenden Sie zum Beispiel die folgende Abfrage:

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

Wenn Sie die einer bestimmten TPU-Arbeitslast zugeordneten Logs mit einem Kubernetes-Job aufrufen möchten, können Sie die Logs mit dem Label batch.kubernetes.io/job-name filtern. Für den Job mnist-training-job können Sie beispielsweise die folgende Abfrage für die STDOUT-Logs ausführen:

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

Wenn Sie die Logs für eine TPU-Arbeitslast mit einem Kubernetes-JobSet aufrufen möchten, können Sie die Logs mit dem Label k8s-pod/jobset_sigs_k8s_io/jobset-name filtern. Beispiel:

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

Wenn Sie die Daten weiter aufschlüsseln möchten, können Sie nach den anderen Arbeitslastlabels filtern. Wenn Sie beispielsweise die Logs für eine Multi-Slice-Arbeitslast vom Worker 0 und dem Slice 1 aufrufen möchten, können Sie nach den Labels filtern: job-complete-index und 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"

Sie können auch mit dem Pod-Namensmuster filtern:

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

In der folgenden Abfrage ist beispielsweise jobSetName ein Multi-Slice-Job und das replicateJobName ein Slice. Sowohl job-index als auch worker-index sind 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"

Bei anderen TPU-Arbeitslasten, z. B. eine einzelne GKE-Pod-Arbeitslast, können Sie die Logs nach Pod-Namen filtern. Beispiel:

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

Wenn Sie prüfen möchten, ob das TPU-Geräte-Plug-in ordnungsgemäß ausgeführt wird, können Sie mit der folgenden Abfrage die zugehörigen Containerlogs überprüfen:

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

Führen Sie die folgende Abfrage aus, um die zugehörigen Ereignisse zu prüfen:

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

Sie können für alle Abfragen zusätzliche Filter wie Clustername, Standort und Projekt-ID hinzufügen. Sie können Bedingungen auch kombinieren, um die Ergebnisse einzugrenzen. Beispiel:

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")

Der Operator AND ist zwischen Vergleichen optional und kann weggelassen werden. Weitere Informationen zur Abfragesprache finden Sie in der Spezifikation der Logging-Abfragesprache. Weitere Abfragebeispiele finden Sie unter Kubernetes-bezogene Logabfragen.

Wenn Sie SQL mit Loganalysen verwenden möchten, finden Sie Abfragebeispiele unter SQL-Abfrage mit Loganalysen. Alternativ können Sie die Abfragen auch mit der Google Cloud CLI statt im Log-Explorer ausführen. Beispiel:

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

Nächste Schritte

Wenn Sie weitere Unterstützung benötigen, wenden Sie sich an den Cloud Customer Care.