Fehlerbehebung bei TPUs in GKE

Standard

---

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 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 Ihr TPU-Kontingentlimit und die aktuelle Nutzung zu prüfen.

Hinweis: Zum Erstellen von TPU-Knoten in GKE ist ein Kontingent für die Compute Engine API erforderlich. Das Compute Engine API-Kontingent (compute.googleapis.com) ist nicht mit dem Cloud TPU API-Kontingent (tpu.googleapis.com) identisch, das beim Erstellen von TPUs mit der Cloud TPU API erforderlich ist.

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 Quota aus und geben Sie basierend auf der TPU-Version und dem Maschinentyp den Namen des Kontingents ein. Wenn Sie beispielsweise On-Demand-TPU v5e-Knoten erstellen möchten, deren Maschinentyp mit ct5lp- beginnt, geben Sie TPU v5 Lite PodSlice chips ein.

      TPU-Version	Maschinentyp beginnt mit	Name des Kontingents für On-Demand-Instanzen	Name des Kontingents für Spot-VMs^1-Instanzen	Name des Kontingents für reservierte ^2-Instanzen
      TPU v4	ct4p-	TPU v4 PodSlice chips	Preemptible TPU v4 PodSlice chips	Committed TPU v4 PodSlice chips
      TPU v5e	ct5l-	TPU v5 Lite Device chips	Preemptible TPU v5 Lite Device chips	Committed TPU v5 Lite Device chips
      TPU v5e	ct5lp-	TPU v5 Lite PodSlice chips	Preemptible TPU v5 Lite PodSlice chips	Committed TPU v5 Lite PodSlice chips

   3. Optional können Sie weitere Filter anwenden, um die Ergebnisse einzugrenzen. Wählen Sie dazu das Attribut Dimensionen (z. B. Standorte) aus und fügen Sie den Namen der Region hinzu, in der Sie TPUs in GKE erstellen möchten. Drücken Sie die Eingabetaste. Geben Sie beispielsweise region:us-west4 ein, wenn Sie TPU v5e-Knoten in der Zone us-west4-a erstellen möchten.

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

1. Verwenden Sie beim Erstellen eines TPU-Knotenpools das Flag --spot, um eine Spot-VM-Instanz zu erstellen. ↩

2. Verwenden Sie beim Erstellen eines TPU-Knotenpools das Flag --reservation, um eine reservierte Instanz zu erstellen. Beim Kauf einer Zusicherung sind TPU-Reservierungen verfügbar. ↩

Erhöhung des TPU-Kontingents anfordern

Wenn Sie ein größeres Kontingent zum Erstellen von TPU-Knoten in GKE benötigen, wenden Sie sich an Ihren Google Cloud-Kundenbetreuer, um eine Erhöhung Ihres TPU-Kontingents zu beantragen. Die mit GKE bereitgestellten TPUs verwenden das zugewiesene Kontingent der Compute Engine API. Das für das Cloud TPU API-Kontingent angeforderte Kontingent gilt nicht für die Verwendung von TPUs in GKE.

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.

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

GKE stellt TPU-Knoten nicht automatisch bereit

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

Fehlkonfiguration einschränken

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

• 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 Ressourcenlimits überschreitet, wird in den Sichtbarkeitslogs des Cluster Autoscaler die 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 zur Behebung dieser Probleme 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 Sie müssen Ressourcen für Nicht-TPU-Knotenpools wie Systemarbeitslasten hinzufügen.

2. Rufen Sie eine Beschreibung der verfügbaren TPUs, CPUs und 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 Beschreibungszeile, die in etwa so aussieht:

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

3. Berechnen Sie die Gesamtzahl der CPU und des Arbeitsspeichers, indem Sie diese Anzahl mit der erforderlichen Anzahl an Knoten 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 einer Marge 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

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 in der Pod-Spezifikation falsch oder fehlen. GKE stellt keine TPU-Knotenpools bereit und die automatische Knotenbereitstellung kann den Cluster nicht hochskalieren.
• Die Pod-Spezifikation gibt google.com/tpu nicht in ihren Ressourcenanforderungen an.

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

1. Prüfen Sie, ob die Arbeitslastknotenauswahl keine nicht unterstützten Labels enthält. Beispielsweise wird durch einen Knotenselektor für das Label cloud.google.com/gke-nodepool verhindert, dass GKE zusätzliche Knotenpools für Ihre Pods erstellt.
2. Die Pod-Vorlagenspezifikationen, in denen Ihre TPU-Arbeitslast ausgeführt wird, müssen die folgenden Werte enthalten:
   • Die Labels cloud.google.com/gke-tpu-accelerator und cloud.google.com/gke-tpu-topology in nodeSelector.
   • google.com/tpu in der Anfrage an.

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.

TPU-Initialisierung fehlgeschlagen

Das folgende Problem tritt auf, wenn GKE neue TPU-Arbeitslasten aufgrund fehlender Berechtigungen für den Zugriff auf TPU-Geräte nicht 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 ist darauf zurückzuführen, 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, um us-central2 für Ihr Google Cloud-Projekt sichtbar zu machen.

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 verwenden (für die Subnetzerstellung).

Um dieses Problem zu beheben, müssen Sie in der Region vor dem Erstellen des GKE-Clusters ein benutzerdefiniertes Subnetz erstellen. Dieses Subnetz darf sich nicht mit anderen Subnetzen überschneiden, die in anderen Regionen im selben VPC-Netzwerk erstellt wurden.