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

Zum Beheben dieses Problems führen Sie ein Upgrade Ihres GKE-Clusters auf Version 1.27.6 oder höher durch.

GKE stellt TPU-Knoten nicht automatisch bereit

In den folgenden Abschnitten wird beschrieben, in welchen Fällen GKE TPU-Knoten nicht automatisch bereitstellt, und wie Sie diese beheben.

Fehlkonfiguration einschränken

GKE stellt TPU-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-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-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-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-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-Knotenpools bereitstellen und die automatische Knotenbereitstellung kann den Cluster nicht hochskalieren.
  • In der Pod-Spezifikation wird google.com/tpu nicht in den Ressourcenanforderungen angegeben.

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 der 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-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-Knoten anfordern. Dies kann beispielsweise der Fall sein, wenn einige Nicht-TPU-Pods bereits auf TPU-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-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.

Nächste Schritte

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