TPUs in GKE


Auf dieser Seite wird Cloud TPU vorgestellt. Außerdem erfahren Sie, wo Sie Informationen zur Verwendung von Cloud TPU mit Google Kubernetes Engine (GKE) finden. Tensor Processing Units (TPUs) sind von Google speziell entwickelte anwendungsspezifische integrierte Schaltungen (Application-Specific Integrated Circuits, ASICs), die verwendet werden, um die beim maschinellen Lernen entstehenden Arbeitslasten zu beschleunigen, die Frameworks wie TensorFlow, PyTorch und JAX nutzen.

Bevor Sie TPUs in GKE verwenden, sollten Sie den folgenden Lernpfad durcharbeiten:

  1. Lernen Sie mit der Einführung in Cloud TPU, wie ML-Beschleuniger funktionieren.
  2. Lernen Sie mehr über die aktuelle Verfügbarkeit von TPU-Versionen unter Cloud TPU-Systemarchitektur.

Informationen zum Einrichten von Cloud TPU in GKE finden Sie in den folgenden Ressourcen:

Vorteile von TPUs in GKE

GKE bietet vollständige Unterstützung für die Verwaltung des TPU-VM-Lebenszyklus, einschließlich Erstellen, Konfigurieren und Löschen von TPU-VMs. GKE unterstützt auch Spot-VMs sowie die Verwendung von reservierten Cloud TPUs. TPUs in GKE bieten folgende Vorteile:

  • Einheitliche Betriebsumgebung: Eine einzige Plattform für alle ML- und sonstigen Arbeitslasten.
  • Automatische Upgrades: GKE automatisiert Versionsupdates, wodurch der operative Aufwand reduziert wird.
  • Load-Balancing: GKE verteilt die Last, um die Latenz zu reduzieren und die Zuverlässigkeit zu verbessern.
  • Responsive Skalierung: GKE skaliert TPU-Ressourcen automatisch entsprechend den Anforderungen Ihrer Arbeitslasten.
  • Ressourcenverwaltung: Mit Kueue, einem nativen Kubernetes-Jobwarteschlangensystem, können Sie Ressourcen über mehrere Mandanten innerhalb Ihrer Organisation verwalten, indem Sie Warteschlangen, vorzeitiges Beenden, Priorisierung und faire Freigabe nutzen.

Terminologie in Bezug auf TPU in GKE

In diesem Dokument wird die folgende Terminologie für TPUs verwendet:

  • TPU-Typ: Der Cloud TPU-Typ, z. B. v5e.
  • TPU-Slice:Eine Reihe miteinander verbundener TPU-Chips.
  • TPU-Topologie: Die Anzahl und die physische Anordnung der TPU-Chips in einem TPU-Slice.
  • TPU-Slice-Knoten mit einzelnem Host: Ein oder mehrere unabhängige TPU-Knoten. Die an die VMs angehängten TPUs sind nicht über Hochgeschwindigkeits-Interconnect-Verbindungen miteinander verbunden.
  • TPU-Slice-Knoten mit mehreren Hosts: zwei oder mehr miteinander verbundene TPU-Knoten. Die an die VMs angehängten TPUs sind über Hochgeschwindigkeits-Verbindungen verbunden. TPU-Knoten mit mehreren Hosts haben folgende Eigenschaften:
    • Atomar: GKE behandelt alle verbundenen Knoten als eine Einheit. Bei Skalierungsvorgängen skaliert GKE den gesamten Satz Knoten auf 0 und erstellt neue Knoten. Wenn eine Maschine in der Gruppe ausfällt oder beendet wird, erstellt GKE den gesamten Satz Knoten als neue Einheit neu.
    • Unveränderlich: Sie können der Gruppe der verbundenen Knoten keine neuen Knoten hinzufügen.

Funktionsweise von TPUs in GKE

Die Kubernetes-Ressourcenverwaltung und -Priorität behandelt TPU-VMs so wie andere VM-Typen. Sie fordern TPU-Chips über den Ressourcennamen google.com/tpu an:

    resources:
        requests:
          google.com/tpu: 4
        limits:
          google.com/tpu: 4

Wenn Sie TPUs in GKE verwenden, müssen Sie die folgenden TPU-Eigenschaften beachten:

  • Eine TPU-VM kann auf bis zu 8 TPU-Chips zugreifen.
  • Ein TPU-Slice enthält eine feste Anzahl von TPU-Chips, die vom ausgewählten TPU-Maschinentyp abhängen.
  • Die Anzahl der angeforderten google.com/tpu muss der Gesamtzahl der verfügbaren Chips auf dem TPU-Knoten entsprechen. Jeder Container in einem GKE-Pod, der TPUs anfordert, muss alle TPU-Chips im Knoten nutzen. Andernfalls schlägt das Deployment fehl, da GKE die TPU-Ressourcen nicht teilweise nutzen kann. Sehen Sie sich beispielsweise die folgenden Szenarien an:
    • Der Maschinentyp ct5l-hightpu-8t hat einen einzelnen TPU-Knoten mit acht TPU-Chips. Ein GKE-Pod, für den acht TPU-Chips erforderlich sind, können auf dem Knoten bereitgestellt werden. Zwei GKE-Pods, die jeweils vier TPU-Chips erfordern, können nicht auf einem Knoten bereitgestellt werden.
    • Der Maschinentyp ct5lp-hightpu-4t mit einer 2x4-Topologie enthält zwei TPU-Knoten mit jeweils vier Chips, insgesamt acht TPU-Chips. Ein GKE-Pod, für den acht TPU-Chips erforderlich sind, kann auf keinem der Knoten in diesem Knotenpool bereitgestellt werden. Es können aber zwei Pods, die jeweils vier TPU-Chips erfordern, auf den beiden Knoten im Knotenpool bereitgestellt werden.
    • TPU v5e mit Topologie 4x4 hat 16 Chips in vier Knoten. Die GKE Autopilot-Arbeitslast, die diese Konfiguration auswählt, muss in jedem Replikat vier Chips für bis zu vier Replikate anfordern.
  • In Standardclustern können mehrere Kubernetes-Pods auf einer TPU-VM geplant werden, aber nur ein Container in jedem Pod kann auf die TPU-Chips zugreifen.
  • Jeder Standard-Cluster benötigt mindestens einen Nicht-TPU-Knotenpool, um kube-system-Pods wie kube-dns zu erstellen.
  • Standardmäßig haben TPU-Knoten die google.com/tpu-Markierung, wodurch verhindert wird, dass Nicht-TPU-Pods auf ihnen geplant werden. Die Markierung sorgt nicht automatisch dafür, dass TPU-Ressourcen vollständig genutzt werden. Sie können Arbeitslasten ausführen, die keine TPUs auf Nicht-TPU-Knoten verwenden, und so TPU-Knoten für Code freigeben, der TPUs verwendet.
  • GKE erfasst die Logs, die von Containern auf TPU-VMs ausgegeben werden. Weitere Informationen finden Sie unter Logging.
  • TPU-Auslastungsmesswerte wie Laufzeitleistung sind in Cloud Monitoring verfügbar. Weitere Informationen finden Sie unter Beobachtbarkeit und Messwerte.

TPU-Konfiguration planen

Um mit TPUs in GKE-Clustern zu arbeiten, müssen Sie die folgenden Parameter festlegen:

  • TPU-Typ: Verschiedene TPU-Typen haben unterschiedliche Funktionen wie Preis-Leistungs-Verhältnis, Trainingsdurchsatz und Bereitstellungslatenz. Die VMs, an die die TPUs angehängt sind, haben unterschiedliche CPU- und Arbeitsspeicherkapazitäten.
  • Topologie: Das Layout der Chips im TPU-Typ. Jeder TPU-Typ unterstützt ein 2D- oder 3D-Chiplayout und bestimmte Anordnungen. Wählen Sie eine Topologie aus, die den Parallelitätsanforderungen Ihres Modells entspricht.
  • TPU-Interconnect-Verbindung:Der TPU-Typ und die Topologie bestimmen, ob Sie TPUs in mehreren Knoten erhalten, die Hochgeschwindigkeitsverbindungen haben. Dadurch wird bestimmt, ob Sie TPU-Slice-Knoten mit einem oder mehreren Hosts verwenden möchten.

    • Verwenden Sie für umfangreiche Modelle TPU-Slice-Knoten mit mehreren Hosts
    • Verwenden Sie für kleine Modelle TPU-Slice-Knoten mit einzelnem Host

TPU-Konfiguration für den GKE Autopilot-Modus auswählen

In Autopilot wählen Sie einen TPU-Typ und eine Topologie aus und geben diese in Ihrem Kubernetes-Manifest an. GKE verwaltet Bereitstellungsknoten mit TPUs und plant Ihre Arbeitslasten.

TPU-Verfügbarkeit in GKE Autopilot

TPUs sind in bestimmten Google Cloud-Regionen verfügbar. Damit Sie einen TPU-Typ in Ihrer GKE-Arbeitslast verwenden können, muss sich der Cluster in einer unterstützten Region für diesen Typ befinden. Weitere Informationen finden Sie in der Cloud TPU-Dokumentation unter TPU-Regionen und -Zonen.

TPU-Typ in Autopilot auswählen

TPU-Typ Anzahl der vCPUs Speicher (GiB) Anzahl der NUMA-Knoten Maximale Anzahl der TPU-Chips in einem Slice
TPU v5p (Vorschau)
tpu-v5p-slice
208 448 2 6.144
TPU v5e
tpu-v5-lite-podslice
24 bis 224 48 bis 384 1 256
TPU v5e (nur einzelner Host)
tpu-v5-lite-device
24 bis 224 48 bis 384 1 bis 2 8
TPU v4
tpu-v4-podslice
240 407 2 4.096

Sehen Sie sich die Chipspezifikationen und Preise in der Cloud TPU-Dokumentation an, um die zu verwendende Version zu bestimmen.

Topologie für Autopilot auswählen

Topologie ist das physische Layout von Chips in einem TPU-Slice. Je nach TPU-Typ ist die Topologie zwei- oder dreidimensional. Nachdem Sie sich für einen TPU-Typ entschieden haben, wählen Sie eine Topologie aus, die von diesem TPU-Typ unterstützt wird. Die Anforderungen an die Parallelität Ihres Modells helfen Ihnen bei der Entscheidung für eine Topologie. Das Produkt der Topologie ist die Anzahl der Chips im Slice. Beispiel:

  • 2x2x2 ist ein TPU v4-Slice mit 8 Chips und mehreren Hosts
  • 2x2 ist ein TPU v5e-Slice mit 4 Chips mit einem Host.

Die Topologie, die Sie für einen TPU-Typ auswählen, bestimmt, ob Sie TPU-Slice-Knoten mit einem oder mehreren Hosts erhalten. Wenn eine bestimmte Topologie sowohl Slices mit einem Host als auch mit mehreren Hosts unterstützt, bestimmt die Anzahl der TPU-Chips, die Ihre Arbeitslastanfragen erhalten, den erhaltenen Hosttyp. Beispielsweise unterstützt TPU v5e (tpu-v5-lite-podslice) die 2x4-Topologie sowohl als einzelne als auch als mehrere Hosts. Wenn Sie in Ihrer Arbeitslast 4 Chips anfordern, erhalten Sie einen Knoten mit mehreren Hosts und 4 Chips. Wenn Sie in Ihrer Arbeitslast 8 Chips anfordern, erhalten Sie einen Knoten mit einem einzelnen Host und 8 Chips.

In der folgenden Tabelle werden die unterstützten Topologien in jedem TPU-Typ sowie die Anzahl der Chips, die Anzahl der Knoten und der Hosttyp beschrieben:

TPU-Typ Topologie TPU-Chips in einem Slice Anzahl von Knoten Hosttyp Notes
TPU v5p (Vorschau)
tpu-v5p-slice
2x2x1 4 1 Einzelner Host

Benutzerdefinierte Topologien für mehr als 64 Chips werden unterstützt. Dabei gelten folgende Bedingungen:

  • Bei mehr als 64 Chips müssen {A}, {B} und {C} ein Vielfaches von 4 sein
  • Die größte Topologie ist 16x16x24.
  • Die Werte müssen {A}{B}{C} sein, z. B. 8x12x16.
2x2x2 8 2 Mehrere Hosts
2x2x4 16 4 Mehrere Hosts
2x4x4 32 8 Mehrere Hosts
4x4x4 64 16 Mehrere Hosts
{A}x{B}x{C} A*B*C (A*B*C/4)1 Mehrere Hosts
TPU v5e
tpu-v5-lite-podslice
1x1 1 1 Einzelner Host Benutzerdefinierte Topologien werden nicht unterstützt.
2x2 4 1
2x4 8 1
2x4 2 1 Mehrere Hosts
4x4 16 4
4x8 32 8
8x8 64 16
8x16 128 32
16x16 256 64
TPU v5e (nur einzelner Host)
tpu-v5-lite-device
1x1 1 1 Einzelner Host Benutzerdefinierte Topologien werden nicht unterstützt
2x2 4 1
2x4 8 1
TPU v4
tpu-v4-podslice
2x2x1 4 1 Einzelner Host

Benutzerdefinierte Topologien für mehr als 64 Chips werden unterstützt. Dabei gelten folgende Bedingungen:

  • Bei mehr als 64 Chips müssen {A}, {B} und {C} ein Vielfaches von 4 sein
  • Die größte Topologie ist 12x16x16.
  • Die Werte müssen {A}{B}{C} sein, z. B. 8x12x16.
2x2x2 8 2 Mehrere Hosts
2x2x4 16 4 Mehrere Hosts
2x4x4 32 8 Mehrere Hosts
4x4x4 64 16 Mehrere Hosts
{A}x{B}x{C} A*B*C (A*B*C/4)1 Mehrere Hosts
  1. Berechnet sich aus dem Topologieprodukt geteilt durch vier.

Nachdem Sie einen TPU-Typ und eine Topologie ausgewählt haben, geben Sie diese in Ihrem Arbeitslastmanifest an. Eine Anleitung finden Sie unter TPU-Arbeitslasten in GKE Autopilot bereitstellen.

TPU-Konfiguration für den GKE-Standardmodus auswählen

In den folgenden Abschnitten werden die TPU-Eigenschaften beschrieben, die Sie bei der Planung und Einrichtung Ihrer TPU-Arbeitslasten in GKE berücksichtigen. Weitere Informationen zu verfügbaren Versionen, zum Maschinentypen, zu gültigen Topologien und zur Anzahl der Chips finden Sie in diesem Dokument unter Zuordnung von TPU-Konfigurationen.

TPU-Verfügbarkeit im GKE-Standardmodus

In der folgenden Tabelle ist die TPU-Verfügbarkeit abhängig vom Maschinentyp und der Version aufgeführt:

TPU-Version Maschinentyp beginnt mit Mindestversion für GKE Verfügbarkeit Zone
TPU v4 ct4p- 1.26.1-gke.1500 Allgemein verfügbar us-central2-b
TPU v5e ct5l- 1.27.2-gke.2100 Allgemein verfügbar europe-west4-b
us-central1-a
TPU v5e ct5lp- 1.27.2-gke.2100 Allgemein verfügbar europe-west4-a1
us-central1-a1
us-east1-c
us-east5-b1
us-west1-c
us-west4-a
us-west4-b1
TPU v5p ct5p- 1.28.3-gke.1024000 Vorschau us-east1-d
us-east5-a
us-east5-c
  1. Beim Erstellen einer TPU v5e mit einem Maschinentyp, der mit ct5lp- in einer der Zonen europe-west4-a, us-central1-a, us-east5-b oder us-west4-b beginnt, werden TPU v5e-Knotenpools mit einzelnen Hosts nicht unterstützt. Mit anderen Worten: Beim Erstellen eines TPU v5e-Knotenpools in einer dieser Zonen wird nur der Maschinentyp ct5lp-hightpu-4t mit einer Topologie von mindestens 2x4 oder höher unterstützt. Um eine TPU v5e mit einzelnem Host in us-central1 oder europe-west4 zu erstellen, wählen Sie die Zonen aus, us-central1-a oder europe-west4-b, und verwenden Maschinentypen, die mit ct5l- beginnen, z. B. ct5l-hightpu-1t, ct5l-hightpu-4t, oder ct5l-hightpu-8t “ Wählen Sie zum Erstellen einer TPU v5e mit einzelnem Host in der Region us-west4 die Zone us-west4-a aus und verwenden Sie Maschinentypen, die mit ct5lp- beginnen, z. B. ct5lp-hightpu-1t. Beachten Sie, dass für Maschinentypen, die mit ct5l- beginnen, ein anderes Kontingent erforderlich ist als für Maschinentypen, die mit ct5lp- beginnen.

In den folgenden Abschnitten werden die TPU-Eigenschaften beschrieben, die Sie bei der Planung und Einrichtung Ihrer TPU-Arbeitslasten in GKE berücksichtigen. Weitere Informationen zu verfügbaren Versionen, zum Maschinentypen, zu gültigen Topologien und zur Anzahl der Chips finden Sie in diesem Dokument unter Zuordnung von TPU-Konfigurationen.

Maschinentyp

Maschinentypen, die TPU-Ressourcen unterstützen, folgen einer Namenskonvention, die die TPU-Version und die Anzahl der Chips pro Knoten wie ct<version>-hightpu-<node-chip-count>t enthält. Der Maschinentyp ct5lp-hightpu-1t unterstützt beispielsweise TPU v5e und enthält insgesamt einen TPU-Chip.

Topologie

Die Topologie definiert die physische Anordnung von TPUs in einem TPU-Slice. GKE stellt ein TPU-Slice in zwei- oder dreidimensionalen Topologien bereit, je nach TPU-Version. Sie geben eine Topologie als Anzahl der TPU-Chips in jeder Dimension an:

  • Für TPU v4 und v5p, das in TPU-Slice-Knotenpools mit mehreren Hosts geplant ist, definieren Sie die Topologie in 3-Tupeln ({A}x{B}x{C}), z. B. 4x4x4. Das Produkt von {A}x{B}x{C} definiert die Anzahl der Chips im Knotenpool. Beispielsweise können Sie kleine Topologien mit weniger als 64 Chips mit Topologieformen wie 2x2x2, 2x2x4 oder 2x4x4 definieren. Wenn Sie Topologien mit mehr als 64 Chips verwenden, müssen die Werte, die Sie {A}, {B} und {C} zuweisen, die folgenden Bedingungen erfüllen:

    • {A}, {B} und {C} sind Vielfache von vier.
    • Die größte Topologie, die für v4 unterstützt wird, ist 12x16x16 und v5p ist 16x16x24.
    • Die zugewiesenen Werte entsprechen dem Muster A ≤ B ≤ C. Beispiel: 4x4x8 oder 8x8x8.

Zuordnung der TPU-Konfiguration

Verwenden Sie die folgende Tabelle, um den TPU-Maschinentyp und die Topologie zu definieren, die basierend auf Ihrem Anwendungsfall verwendet werden sollen:

  • Verwenden Sie für kleines Modelltraining oder Inferenz TPU v4 oder TPU v5e mit TPU-Slice-Knotenpools mit einem Host.
  • Verwenden Sie für umfangreiches Modelltraining oder Inferenz TPU v4 oder TPU v5e mit TPU-Slice-Knotenpools mit mehreren Hosts.
TPU-Version Maschinentyp Topologie Anzahl der TPU-Chips Anzahl der VMs Knotenpooltyp
TPU v4 ct4p-hightpu-4t 2x2x1 4 1 Einzelner Host
2x2x2 8 2 Mehrere Hosts
2x2x4 16 4 Mehrere Hosts
2x4x4 32 8 Mehrere Hosts
{A}x{B}x{C} A*B*C (A*B*C/4)1 Mehrere Hosts
TPU v5p ct5p-hightpu-4t 2x2x1 4 1 Einzelner Host
2x2x2 8 2 Mehrere Hosts
2x2x4 16 4 Mehrere Hosts
2x4x4 32 8 Mehrere Hosts
{A}x{B}x{C} A*B*C (A*B*C/4)1 Mehrere Hosts
TPU v5e ct5l-hightpu-1t 1x1 1 1 Einzelner Host
ct5l-hightpu-4t 2x2 4 1 Einzelner Host
ct5l-hightpu-8t 2x4 8 1 Einzelner Host
ct5lp-hightpu-1t 1x1 1 1 Einzelner Host
ct5lp-hightpu-4t 2x2 4 1 Einzelner Host
ct5lp-hightpu-8t 2x4 8 1 Einzelner Host
ct5lp-hightpu-4t 2x4 8 2 Mehrere Hosts
4x4 16 4 Mehrere Hosts
4x8 32 8 Mehrere Hosts
8x8 64 16 Mehrere Hosts
8x16 128 32 Mehrere Hosts
16x16 256 64 Mehrere Hosts
  1. Berechnet sich aus dem Topologieprodukt geteilt durch vier.

TPU v5e-Eigenschaften

TPU v5e-Maschinen haben die folgenden technischen Eigenschaften:

Maschinentyp Anzahl der vCPUs Arbeitsspeicher (GB) Anzahl der NUMA-Knoten Wahrscheinlichkeit eines vorzeitigen Beendens
ct5l-hightpu-1t 24 48 1 Höher
ct5l-hightpu-4t 112 192 1 Mittel
ct5l-hightpu-8t 224 384 2 Niedrigere
ct5lp-hightpu-1t 24 48 1 Höher
ct5lp-hightpu-4t 112 192 1 Mittel
ct5lp-hightpu-8t 224 384 1 Niedrig

TPU v4- und v5p-Eigenschaften

TPU v4p- und v5p-Maschinen haben die folgenden technischen Eigenschaften:

Maschinentyp Anzahl der vCPUs Arbeitsspeicher (GB) Anzahl der NUMA-Knoten
ct4p-hightpu-4t 240 407 2
ct5p-hightpu-4t 208 448 2

TPU-Reservierung

Damit TPU-Ressourcen bei Bedarf verfügbar sind, können Sie in den folgenden Szenarien TPU-Reservierungen verwenden:

  • Wenn Sie bereits TPU-Reservierungen haben, müssen Sie mit Ihrem Google Cloud-Account-Management-Team zusammenarbeiten, um Ihre TPU-Reservierung in ein neues Compute Engine-basiertes Reservierungssystem zu migrieren.

  • Wenn Sie keine TPU-Reservierung haben, können Sie eine TPU-Reservierung erstellen. Dann ist keine Migration erforderlich.

Autoscaling von TPUs in GKE

GKE unterstützt Tensor Processing Units (TPUs), um ML-Arbeitslasten zu beschleunigen. Sowohl der TPU-Slice-Knotenpool mit einem einzelnen Host als auch der TPU-Slice-Knotenpool mit mehreren Hosts unterstützen Autoscaling und die automatische Bereitstellung.

Mit dem Flag --enable-autoprovisioning in einem GKE-Cluster erstellt oder löscht GKE TPU-Slice-Knotenpools mit einem oder mehreren Hosts mit einer TPU-Version und Topologie, die die Anforderungen ausstehender Arbeitslasten erfüllt.

Wenn Sie --enable-autoscaling verwenden, skaliert GKE den Knotenpool basierend auf seinem Typ so:

  • Einzelner Host TPU-Slice-Knotenpool: GKE fügt dem vorhandenen Knotenpool TPU-Knoten hinzu oder entfernt sie. Der Knotenpool kann eine beliebige Anzahl von TPU-Knoten zwischen null und der maximalen Größe des Knotenpools enthalten, wie durch --max-nodes und die --total-max-nodes-Flags bestimmt. Wenn der Knotenpool skaliert wird, haben alle TPU-Knoten im Knotenpool denselben Maschinentyp und dieselbe Topologie. Weitere Informationen zum Erstellen eines TPU-Slice-Knotenpools mit einem Host finden Sie unter Knotenpool erstellen.

  • TPU-Slice-Knotenpool mit mehreren Hosts: GKE skaliert den Knotenpool in kleinstmöglichen Schritten von null auf die Anzahl der Knoten, die für die TPU-Topologie erforderlich sind. Bei einem TPU-Knotenpool mit dem Maschinentyp ct5lp-hightpu-4t und der Topologie 16x16 enthält der Knotenpool beispielsweise 64 Knoten. GKE Autoscaling sorgt dafür, dass dieser Knotenpool genau 0 oder 64 Knoten hat. Beim Herunterskalieren entfernt GKE alle geplanten Pods und leert den gesamten Knotenpool auf null. Weitere Informationen zum Erstellen eines TPU-Slice-Knotenpools mit mehreren Hosts finden Sie unter Knotenpool erstellen.

Beschränkungen

  • Für Kapazitätsreservierungen müssen Sie eine bestimmte Reservierung verwenden.
  • Die GKE-Kostenzuordnung und -Nutzungsmessung enthält keine Daten zur Nutzung oder zu den Kosten der reservierten TPU v4.
  • TPU v5p und v5e unterstützen kein Riptide-/Image-Streaming in us-east5.

Überlegungen zur Arbeitslastplanung

TPUs haben besondere Merkmale, die eine spezielle Arbeitslastplanung und -verwaltung in Kubernetes erfordern. In den folgenden Abschnitten finden Sie Best Practices für die Planung.

CPU

Dieser Abschnitt gilt nicht für Autopilot-Cluster, da GKE jeden TPU-Pod auf einem eigenen Knoten platziert.

Sorgen Sie dafür, dass Ihr GKE-Pod die google.com/tpu-Markierung tolerieren kann, um eine Arbeitslast auf der Onboard-CPU auf einer TPU-VM zu planen. Wenn Sie die Arbeitslast für bestimmte Knoten bereitstellen möchten, verwenden Sie die Knotenauswahl.

Die Kubernetes-Ressourcenverwaltung und -Priorität behandelt TPU-VMs so wie andere VM-Typen. Damit Pods, die TPU-Planung erfordern, Vorrang vor anderen Pods auf denselben Knoten haben, fordern Sie die maximale CPU- oder Arbeitsspeichermenge für diese TPU-Pods an. Pods mit niedriger Priorität sollten folgende Voraussetzungen erfüllen:

  1. Legen Sie niedrige CPU- und Speicheranforderungen fest, damit der Knoten genügend zuweisbare Ressourcen für die TPU-Arbeitslasten hat. Weitere Informationen finden Sie unter So wendet Kubernetes Ressourcenanfragen und -limits an.
  2. Legen Sie kein CPU-Limit (unbegrenzt) fest, damit die Pods Bursts verwenden können, um alle nicht verwendeten Zyklen zu nutzen.
  3. Legen Sie ein hohes Arbeitsspeicherlimit fest, damit Pods den meisten nicht verwendeten Arbeitsspeicher verwenden können, ohne die Stabilität der Knoten zu beeinträchtigen.

Wenn ein Kubernetes-Pod keine CPUs und keinen Arbeitsspeicher anfordert (selbst wenn er TPUs anfordert), betrachtet Kubernetes ihn als Best-Effort-Pod und es gibt keine Garantie dafür, dass CPU und Arbeitsspeicher benötigt werden. Nur Pods, die explizit CPU und Arbeitsspeicher anfordern, haben solche Garantien. Weitere Informationen finden Sie unter Ressourcenverwaltung für Pods und Container.

Weitere Informationen finden Sie unter Best Practices für Kubernetes: Ressourcenanforderungen und -limits.

Unterbrechungsfreie Arbeitslast-Laufzeit maximieren

Wenn Sie TPUs zum Trainieren eines Modells für maschinelles Lernen verwenden und Ihre Arbeitslast unterbrochen wird, geht alle seit dem letzten Prüfpunkt ausgeführte Arbeit verloren. So verringern Sie die Wahrscheinlichkeit, dass Ihre Arbeitslast unterbrochen wird:

  • Legen Sie eine höhere Priorität für diesen Job als für alle anderen Jobs fest: Wenn die Ressourcen knapp sind, vorzeitig beendet der GKE-Planer Jobs mit niedrigerer Priorität vorzeitig, um einen Job mit höherer Priorität zu planen. Darüber hinaus wird damit sichergestellt, dass Ihre Arbeitslast mit höherer Priorität alle erforderlichen Ressourcen erhält (bis zu den insgesamt im Cluster verfügbaren Ressourcen). Weitere Informationen finden Sie unter Pod-Priorität und vorzeitiges Beenden.
  • Konfigurieren Sie einen Wartungsausschluss: Ein Wartungsausschluss ist ein sich nicht wiederholender Zeitraum, in dem keine automatische Wartung stattfinden darf. Weitere Informationen finden Sie unter Wartungsausschlüsse.
  • Pods mit verlängerter Laufzeit in Autopilot verwenden: Verwenden Sie Pods mit verlängerter Laufzeit für einen Kulanzzeitraum von bis zu sieben Tagen, bevor GKE Ihre Pods für Herunterskalierungen oder Knotenupgrades beendet. “

TPU-Auslastung maximieren

Um Ihre Investition in TPUs zu maximieren, planen Sie eine Mischung von Jobprioritäten und stellen Sie sie in eine Warteschlange, um die Betriebszeit Ihrer TPUs zu maximieren. Wenn Sie Planung und vorzeitiges Beenden auf Jobebene wünschen, müssen Sie ein Add-on zu Kubernetes verwenden, das Jobs in Warteschlangen orchestriert. Für diesen Anwendungsfall empfehlen wir die Verwendung von Kueue.

Nächste Schritte