Fehlerbehebung bei TPUs in GKE

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

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

Ein Fehler wie Insufficient quota to satisfy the request gibt an, dass IhrGoogle 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

In den folgenden Abschnitten erfahren Sie, wie Sie sicherstellen können, dass Sie bei der Verwendung von TPUs in GKE über ausreichendes Kontingent verfügen.

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 anhand der folgenden Tabelle das Attribut des Kontingents basierend auf der TPU-Version und dem Maschinentyp aus und kopieren Sie es . Wenn Sie beispielsweise On-Demand-TPU v5e-Knoten erstellen möchten, deren Maschinentyp mit Name: TPU v5 Lite PodSlice chips beginnt, geben Sie ein.

      TPU-Version Property und Name des Kontingents für On-Demand-Instanzen Property und Name des Kontingents für Spot2-Instanzen
      TPU v3,
      		 
      Dimensions (e.g. location):
      tpu_family:CT3
      		 Nicht zutreffend
      TPU v3,
      		 
      Dimensions (e.g. location):
      tpu_family:CT3P
      		 Nicht zutreffend
      TPU v4,
      		 
      Name:
      TPU v4 PodSlice chips
      		 
      Name:
      Preemptible TPU v4 PodSlice chips
      TPU v5e,
      		 
      Name:
      TPU v5 Lite PodSlice chips
      		 
      Name:
      Preemptible TPU v5 Lite Podslice
      chips
      TPU v5p,
      		 
      Name:
      TPU v5p chips
      		 
      Name:
      Preemptible TPU v5p chips
      TPU Trillium,
      		 
      Dimensions (e.g. location):
      tpu_family:CT6E
      		 
      Name:
      Preemptible TPU slices v6e

    2. 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-Kontingentanpassung anfordern.

Wenn eine TPU-Reservierung erstellt wird, erhöhen sich sowohl der Limitwert als auch der Wert der aktuellen Nutzung für das entsprechende Kontingent um die Anzahl der Chips in der TPU-Reservierung. Wenn beispielsweise eine Reservierung für 16 TPU v5e-Chips erstellt wird, deren Maschinentyp mit beginnt, sind sowohl die Begrenzung als auch die aktuelle Nutzung für das Kontingent TPU v5 Lite PodSlice chips in der entsprechenden Region um 16 erhöht.

Kontingente für zusätzliche GKE-Ressourcen

Möglicherweise müssen Sie die folgenden GKE-bezogenen Kontingente in den Regionen erhöhen, in denen GKE Ihre Ressourcen erstellt.

  • Kontingent für Persistent Disk SSD (GB): 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 erstellen werden, und 100 GB (Knoten × 100 GB) sein.
  • Kontingent für verwendete IP-Adressen: Jeder Kubernetes-Knoten verbraucht eine IP-Adresse. Daher sollte dieses Kontingent mindestens so hoch sein wie die maximale Anzahl von GKE-Knoten, die Sie voraussichtlich erstellen werden.
  • Achten Sie darauf, dass max-pods-per-node mit dem Subnetzbereich übereinstimmt: Jeder Kubernetes-Knoten verwendet sekundäre IP-Bereiche für Pods. Für max-pods-per-node von 32 sind beispielsweise 64 IP-Adressen erforderlich, was einem /26-Subnetz pro Knoten entspricht. Dieser Bereich darf nicht für andere Cluster freigegeben werden. Verwenden Sie das Flag --max-pods-per-node, um die Anzahl der Pods zu begrenzen, die auf einem Knoten geplant werden dürfen, damit der IP-Adressbereich nicht ausgeschöpft wird. Das Kontingent für max-pods-per-node sollte mindestens so hoch sein wie die maximale Anzahl von GKE-Knoten, die Sie voraussichtlich erstellen werden.

Informationen zum Anfordern einer Kontingenterhöhung finden Sie unter Kontingentanpassung anfordern.

Unzureichende TPU-Ressourcen, um die TPU-Anfrage zu erfüllen

Ein Fehler, der GCE_STOCKOUT enthält, weist darauf hin, dass TPU-Ressourcen vorübergehend nicht verfügbar sind, um die Anfrage zu erfüllen. GKE erfüllt die Bereitstellungsanfrage, sobald TPU-Ressourcen verfügbar sind.

Sie haben folgende Möglichkeiten, dieses Problem zu beheben:

Informationen zum Auswählen der Nutzungsoption, die Ihren Arbeitslastanforderungen entspricht, finden Sie unter Beschleuniger-Nutzungsoptionen für KI-/ML-Arbeitslasten in GKE.

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

Wenn die Limits für die automatische Bereitstellung Ihres Clusters fehlen oder zu niedrig sind, stellt GKE keine TPU-Slice-Knoten automatisch bereit. In solchen Szenarien können Sie die folgenden Fehler beobachten:

  • Wenn GKE versucht, einen TPU-Slice-Knotenpool automatisch bereitzustellen, für den keine Limits definiert sind, wird in den Logs zur Cluster-Autoscaling-Sichtbarkeit folgende Fehlermeldung angezeigt:

    messageId: "no.scale.up.nap.pod.tpu.no.limit.defined"

  • 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 Konsole 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 Konsole 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 Maschinentyp, nach dem gesucht werden soll.
    • COMPUTE_ZONE: Der Name der Computing-Zone.

    Die Ausgabe enthält eine Zeile mit einer Beschreibung, die 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. Um Kapazitätsprobleme zu vermeiden, können Sie Reservierungen verwenden oder Spot-VMs in Betracht ziehen.

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 der Knotenauswahl für Ihre Arbeitslast nicht unterstützte 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 der 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 Fehlerbehebung für JobSet. 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 GKE aufgrund fehlender Berechtigungen für den Zugriff auf TPU-Geräte keine neuen TPU-Arbeitslasten bereitstellen kann.

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 tritt auf, weil 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 IhremGoogle 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.

Schreibgeschützten Kubelet-Port aktivieren

Wenn Sie eine GKE-Clusterversion vor 1.32 verwenden, prüfen Sie, ob das Feld insecureKubeletReadonlyPortEnabled auf true festgelegt ist.

Sie können den Wert des Felds insecureKubeletReadonlyPortEnabled prüfen, indem Sie Ihren Knotenpool beschreiben:

gcloud container node-pools describe NODEPOOL_NAME --cluster=CLUSTER_NAME

Wenn die Ausgabe insecureKubeletReadonlyPortEnabled: false enthält, aktivieren Sie den Port mit dem folgenden Befehl:

gcloud container node-pools update NODEPOOL_NAME --cluster CLUSTER_NAME --enable-insecure-kubelet-readonly-port

In den folgenden Beispielfehlern wird ein TCP-Verbindungsfehler zu Port 10255 erwähnt. Das deutet darauf hin, dass Sie den Port möglicherweise aktivieren müssen.

error sending request: Get "http://gke-tpu-d32e5ca6-f4gp:10255/pods": GET http://gke-tpu-d32e5ca6-f4gp:10255/pods giving up after 5 attempt(s): Get "http://gke-tpu-d32e5ca6-f4gp:10255/pods": dial tcp [2600:1901:8130:662:0:19c::]:10255: connect: connection refused

failed to get TPU container Info: failed to call kubelet: Get "http://gke-tpu-d32e5ca6-f4gp:10255/pods": GET http://gke-tpu-d32e5ca6-f4gp:10255/pods giving up after 5 attempt(s): Get "http://gke-tpu-d32e5ca6-f4gp:10255/pods": dial tcp [2600:1901:8130:662:0:19c::]:10255: connect: connection refused

Verbindungsfehler beim Ausführen einer Trainingsarbeitslast mit JAX

Wenn Sie versuchen, das JAX-Framework zu initialisieren, um eine Trainingsarbeitslast auf TPU-Maschinen auszuführen, wird möglicherweise eine Fehlermeldung ähnlich der folgenden angezeigt:

E0115 19:06:10.727412 340 master.cc:246] Initialization of slice failed with
error status: INVALID_ARGUMENT: When linking node TPU_ID:pe0:0
to TPU_ID:pe0:3</code> with link TPU_ID:pe0:0:p5:x couldn't find opposite link in destination node.; Failed to create the mesh (xW, xW, xW); Please make sure the topology is correct.;
Failed to discover ICI network topology

Dieser Fehler tritt auf, wenn GKE die Netzwerk-Topologie für Hochgeschwindigkeits-Verbindungen zwischen den Chips (ICI) für große TPU-Slices nicht einrichten kann.

So beheben Sie das Problem:

  1. Ermitteln Sie die TPU-Slices, bei denen der Verbindungsfehler auftritt. Verwenden Sie die folgende Abfrage, um die Ereignisprotokolle aufzurufen:

    resource.type="k8s_container"
resource.labels.project_id=PROJECT_ID
severity>=DEFAULT
SEARCH("`[/dev/vfio/0` `TPU_ID` Driver `opened.`")

    Ersetzen Sie Folgendes:

    • PROJECT_ID: Ihre Projekt-ID.
    • TPU_ID: die ID der TPU, bei der Fehler auftreten. Die TPU-ID wird in der Fehlermeldung angezeigt.

  2. Weisen Sie dem Knotenpool oder einem der in der Fehlermeldung enthaltenen Knoten eine Taint-Kennzeichnung zu. Weitere Informationen finden Sie unter Knotenpool für Arbeitslasten markieren und mit Labels versehen.

  3. Führen Sie den Job noch einmal in einem anderen Knotenpool aus.

Wenn das Problem weiterhin besteht, erstellen Sie ein Support-Ticket oder wenden Sie sich an Ihr Kontoteam.

GKE-TPU-Logs ansehen

Wenn Sie alle TPU-bezogenen Logs für eine bestimmte Arbeitslast aufrufen möchten, bietet Cloud Logging einen zentralen Ort zum Abfragen dieser Logs, wenn das GKE-System- und Arbeitslast-Logging aktiviert ist. In Cloud Logging werden Logs in Logeinträge unterteilt. Jeder einzelne Logeintrag hat ein strukturiertes Format. Das Folgende ist ein Beispiel für einen Logeintrag für einen TPU-Trainingsjob.

{
  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 mit dem Wert, der 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. Mit der folgenden Abfrage werden beispielsweise die Logs des TPU-Knotens gke-tpu-9243ec28-wwf5 angezeigt:

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

GKE fügt allen Knoten mit TPUs das Label cloud.google.com/gke-tpu-accelerator und cloud.google.com/gke-tpu-topology hinzu. 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 zusätzlich nach den Knotenlabels und ihren Werten filtern. Mit dem folgenden Befehl werden beispielsweise 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 beispielsweise die folgende Abfrage:

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

Wenn Sie die Logs für eine bestimmte TPU-Arbeitslast 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. Beispiele:

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 nach dem Pod-Namensmuster filtern:

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

In der folgenden Abfrage ist jobSetName beispielsweise ein Job mit mehreren Slices und 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. Beispiele:

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 die folgenden Abfrage verwenden, um die Containerlogs zu prü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 allen Abfragen zusätzliche Filter hinzufügen, z. B. Clusternamen, Standort und Projekt-ID. Sie können auch Bedingungen kombinieren, um die Ergebnisse einzugrenzen. Beispiele:

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 Beispiele für Abfragen 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 anstelle des Log-Explorers ausführen. Beispiele:

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 in der Dokumentation keine Lösung für Ihr Problem finden, lesen Sie den Abschnitt Support erhalten. Dort finden Sie weitere Hilfe, z. B. zu den folgenden Themen: