TPU-Arbeitslasten in GKE Standard bereitstellen

Auf dieser Seite finden Sie die Grundlagen, um zu erfahren, wie Sie Arbeitslasten für maschinelles Lernen (ML) mit TPUs in Google Kubernetes Engine (GKE) beschleunigen können. TPUs sind für die Verarbeitung von Matrixmultiplikationen konzipiert, z. B. für das Training von Deep-Learning-Modellen im großen Maßstab. TPUs sind für die Verarbeitung der enormen Datasets und komplexen Modelle von ML optimiert und daher aufgrund ihrer überlegenen Leistung kostengünstiger und energieeffizienter für ML-Arbeitslasten. In diesem Leitfaden erfahren Sie, wie Sie ML-Arbeitslasten mit Cloud TPU-Beschleunigern bereitstellen, Kontingente für TPUs konfigurieren, Upgrades für Knotenpools konfigurieren, auf denen TPUs ausgeführt werden, und TPU-Arbeitslastmesswerte überwachen.

Diese Anleitung richtet sich an Entwickler von maschinellem Lernen (ML) sowie an Plattformadministratoren und ‑operatoren, die daran interessiert sind, die Kubernetes-Containerorchestrierung zum Verwalten von Arbeitslasten für das Training, die Optimierung und die Inferenz von Modellen in großem Umfang mit TPUs zu verwenden. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die in Google Cloud -Inhalten verwiesen wird, finden Sie unter Häufig verwendete GKE-Nutzerrollen und ‑Aufgaben.

Machen Sie sich vor dem Lesen dieser Seite mit den folgenden Themen vertraut:

Hinweise

Führen Sie die folgenden Aufgaben aus, bevor Sie beginnen:

  • Aktivieren Sie die Google Kubernetes Engine API.
  • Google Kubernetes Engine API aktivieren
  • Wenn Sie die Google Cloud CLI für diesen Task verwenden möchten, müssen Sie die gcloud CLI installieren und dann initialisieren. Wenn Sie die gcloud CLI bereits installiert haben, rufen Sie die neueste Version mit dem Befehl gcloud components update ab. In früheren gcloud CLI-Versionen werden die Befehle in diesem Dokument möglicherweise nicht unterstützt.

TPU-Konfiguration planen

Planen Sie Ihre TPU-Konfiguration basierend auf Ihrem Modell und dem erforderlichen Arbeitsspeicher. Bevor Sie diese Anleitung zum Bereitstellen Ihrer Arbeitslasten auf TPUs verwenden, führen Sie die Planungsschritte unter TPU-Konfiguration planen aus.

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

Kontingent für On-Demand- oder Spot-VMs

Wenn Sie einen TPU-Slice-Knotenpool mit On-Demand- oder Spot-VMs erstellen, müssen Sie in der gewünschten Region über ein ausreichendes TPU-Kontingent verfügen.

Für das Erstellen eines TPU-Slice-Knotenpools, der eine TPU-Reservierung nutzt, ist kein TPU-Kontingent erforderlich.1 Sie können diesen Abschnitt für reservierte TPUs überspringen.

Zum Erstellen eines On-Demand- oder Spot-TPU-Slice-Knotenpools 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.

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. Verwenden Sie die folgende Tabelle, um das Attribut des Kontingents basierend auf der TPU-Version und dem Maschinentyp auszuwählen und zu kopieren. Wenn Sie beispielsweise On-Demand-TPU v5e-Knoten erstellen möchten, deren Maschinentyp mit ct5lp- beginnt, geben Sie Name: TPU v5 Lite PodSlice chips ein.

      TPU-Version, Maschinentyp beginnt mit Property und Name des Kontingents für On-Demand-Instanzen Property und Name des Kontingents für Spot2-Instanzen
      TPU v3,
      ct3-
      Dimensions (e.g. location):
      tpu_family:CT3
      Nicht zutreffend
      TPU v3,
      ct3p-
      Dimensions (e.g. location):
      tpu_family:CT3P
      Nicht zutreffend
      TPU v4,
      ct4p-
      Name:
      TPU v4 PodSlice chips
      Name:
      Preemptible TPU v4 PodSlice chips
      TPU v5e,
      ct5lp-
      Name:
      TPU v5 Lite PodSlice chips
      Name:
      Preemptible TPU v5 Lite Podslice
      chips
      TPU v5p,
      ct5p-
      Name:
      TPU v5p chips
      Name:
      Preemptible TPU v5p chips
      TPU Trillium,
      ct6e-
      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 ct5lp- beginnt, werden 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.

  1. Verwenden Sie beim Erstellen eines TPU-Slice-Knotenpools die Flags --reservation und --reservation-affinity=specific, um eine reservierte Instanz zu erstellen. Beim Kauf einer Zusicherung sind TPU-Reservierungen verfügbar.

  2. Verwenden Sie beim Erstellen eines TPU-Slice-Knotenpools das Flag --spot, um eine Spot-Instanz zu erstellen.

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.

Verfügbarkeit von Reservierungen sichern

Wenn Sie einen TPU-Slice-Knotenpool mit einer Reservierung erstellen möchten, muss die Reservierung zum Zeitpunkt der Erstellung des Knotenpools über genügend verfügbare TPU-Chips verfügen.

Um herauszufinden, welche Reservierungen in einem Projekt bestehen und wie viele TPU-Chips in einer TPU-Reservierung verfügbar sind, rufen Sie eine Liste Ihrer Reservierungen auf.

Optionen für die Bereitstellung von TPUs in GKE

Mit GKE können Sie TPUs direkt in einzelnen Arbeitslasten verwenden. Dazu verwenden Sie Kubernetes-nodeSelectors in Ihrem Arbeitslastmanifest oder erstellen Knotenpools im Standardmodus mit TPUs.

Alternativ können Sie TPUs mit benutzerdefinierten Compute-Klassen anfordern. Mit benutzerdefinierten Compute-Klassen können Plattformadministratoren eine Hierarchie von Knotenkonfigurationen für GKE definieren, die bei Entscheidungen zur Knotenskalierung priorisiert werden sollen, damit Arbeitslasten auf der ausgewählten Hardware ausgeführt werden.

Eine Anleitung finden Sie im Abschnitt TPUs mit benutzerdefinierten Compute-Klassen bereitstellen.

Cluster erstellen

Erstellen Sie einen GKE-Cluster im Standard-Modus in einer Region mit verfügbaren TPUs.

Best Practice:

Verwenden Sie regionale Cluster, die eine hohe Verfügbarkeit der Kubernetes-Steuerungsebene bieten.

gcloud container clusters create CLUSTER_NAME \
  --location LOCATION \
  --cluster-version VERSION

Ersetzen Sie Folgendes:

  • CLUSTER_NAME ist der Name des neuen Clusters.
  • LOCATION: Die Region mit Ihrer verfügbaren TPU-Kapazität.
  • VERSION: Die GKE-Version, die den gewünschten Maschinentyp unterstützen muss. Die GKE-Standardversion ist für Ihre Ziel-TPU möglicherweise nicht verfügbar. Informationen zu den für die TPU-Maschinentypen verfügbaren Mindest-GKE-Versionen finden Sie unter TPU-Verfügbarkeit in GKE.

Knotenpool erstellen

Sie können einen TPU-Slice-Knotenpool mit einem oder mehreren Hosts erstellen.

TPU-Slice-Knotenpool mit einem Host erstellen

Sie können einen TPU-Slice-Knotenpool mit einem einzelnen Host mithilfe der Google Cloud CLI, mit Terraform oder mit der Google Cloud erstellen.

gcloud

gcloud container node-pools create NODE_POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONES \
    --machine-type=MACHINE_TYPE \
    [--sandbox=type=gvisor]

Ersetzen Sie Folgendes:

  • NODE_POOL_NAME: Der Name des neuen Knotenpools.
  • LOCATION: Der Name der Zone basierend auf der zu verwendenden TPU-Version. Informationen dazu, wie Sie einen verfügbaren Standort ermitteln, finden Sie unter TPU-Verfügbarkeit in GKE.
  • CLUSTER_NAME ist der Name des Clusters.
  • NODE_ZONES: Die kommagetrennte Liste mit einer oder mehreren Zonen, in denen GKE den Knotenpool erstellt.
  • MACHINE_TYPE: Der Maschinentyp für Knoten. Weitere Informationen zu TPU-kompatiblen Maschinentypen finden Sie in der Tabelle unter TPU-Version auswählen.

Optional können Sie auch die folgenden Flags verwenden:

  • --num-nodes=NUM_NODES: Die anfängliche Anzahl von Knoten im Knotenpool in jeder Zone. Wenn Sie dieses Flag weglassen, weist GKE den Standardwert 3 zu.

    Best Practice:

    Wenn Sie das Flag enable-autoscaling für den Knotenpool verwenden, legen Sie num-nodes auf 0 fest, damit der Autoscaler zusätzliche Knoten bereitstellt, sobald Ihre Arbeitslasten diese benötigen.

  • --reservation=RESERVATION_NAME: Der Name der Reservierung, die GKE beim Erstellen des Knotenpools verwendet. Wenn Sie dieses Flag weglassen, verwendet GKE die verfügbaren TPUs. Weitere Informationen zu TPU-Reservierungen finden Sie unter Cloud TPU-Reservierungen.

  • --node-labels cloud.google.com/gke-workload-type=HIGH_AVAILABILITY: Gibt GKE, dass der Knotenpool für das TPU-Slice mit einem einzelnen Host Teil einer Sammlung ist. Verwenden Sie dieses Flag, wenn die folgenden Bedingungen erfüllt sind:

    • Der Knotenpool führt die Inferenzarbeitslast im neuen Knotenpool aus.
    • Der Knotenpool verwendet TPU Trillium.
    • Der Knotenpool verwendet keine Spot-VMs.

    Weitere Informationen zur Verwaltung der Erfassungsplanung finden Sie unter Erfassungsplanung in TPU-Slices mit einem Host verwalten.

  • --enable-autoscaling: Knotenpool mit aktiviertem Autoscaling erstellen. Erfordert die folgenden zusätzlichen Flags:

    • --total-min-nodes=TOTAL_MIN_NODES: Mindestanzahl aller Knoten im Knotenpool.
    • --total-max-nodes=TOTAL_MAX_NODES: Maximale Anzahl aller Knoten im Knotenpool.
    • --location-policy=ANY: Die Nutzung nicht verwendeter Reservierungen priorisieren und das Risiko des Vorzeitigen Beendens von Spot-VMs verringern.
  • --spot: Legt fest, dass der Knotenpool Spot-VMs für die Knoten im Knotenpool verwendet. Dies kann nach dem Erstellen des Knotenpools nicht mehr geändert werden.

  • --flex-start: Legt den Knotenpool so fest, dass Flex-Start-VMs verwendet werden. Flex-Start-VMs werden mit der Verbrauchsoption flex-start erstellt, die in GKE-Version 1.33.0-gke.1712000 oder höher unterstützt wird.

  • --sandbox=type=gvisor: Stellt einen Knoten mit aktivierter GKE Sandbox bereit. Erfordert TPU v4 und höher. Weitere Informationen finden Sie unter GKE Sandbox.

Eine vollständige Liste aller Flags, die Sie angeben können, finden Sie in der Referenz zu gcloud container clusters create.

Terraform

  1. Prüfen Sie, ob Sie Version 4.84.0 oder höher des Anbieters google verwenden.
  2. Fügen Sie Ihrer Terraform-Konfiguration den folgenden Block hinzu:
resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
  provider           = google
  project            = PROJECT_ID
  cluster            = CLUSTER_NAME
  name               = POOL_NAME
  location           = CLUSTER_LOCATION
  node_locations     = [NODE_ZONES]

  node_config {
    machine_type = MACHINE_TYPE
    reservation_affinity {
      consume_reservation_type = "SPECIFIC_RESERVATION"
      key = "compute.googleapis.com/reservation-name"
      values = [RESERVATION_LABEL_VALUES]
    }
    spot = true
    flex_start = false
  }
}

Ersetzen Sie Folgendes:

  • NODE_POOL_RESOURCE_NAME: Der Name der Knotenpoolressource in der Terraform-Vorlage.
  • PROJECT_ID: Ihre Projekt-ID.
  • CLUSTER_NAME: Der Name des vorhandenen Clusters.
  • POOL_NAME: Der Name des Knotenpools, der erstellt werden soll.
  • CLUSTER_LOCATION: Die Compute-Zonen des Clusters. Geben Sie die Region an, in der die TPU-Version verfügbar ist. Weitere Informationen finden Sie unter TPU-Version und Topologie auswählen.
  • NODE_ZONES: Die durch Kommas getrennte Liste mit einer oder mehreren Zonen, in denen GKE den Knotenpool erstellt.
  • MACHINE_TYPE: Der zu verwendende TPU-Maschinentyp. Die TPU-kompatiblen Maschinentypen finden Sie in der Tabelle unter TPU-Version auswählen.

Optional können Sie auch die folgenden Variablen verwenden:

  • autoscaling: Knotenpool mit aktiviertem Autoscaling erstellen. Bei einem TPU-Slice mit einem einzelnen Host skaliert GKE zwischen den Werten TOTAL_MIN_NODES und TOTAL_MAX_NODES.
    • TOTAL_MIN_NODES: Mindestanzahl aller Knoten im Knotenpool. Dieses Feld ist optional, es sei denn, Autoscaling ist ebenfalls angegeben.
    • TOTAL_MAX_NODES: Maximale Anzahl aller Knoten im Knotenpool. Dieses Feld ist optional, es sei denn, Autoscaling ist ebenfalls angegeben.
  • RESERVATION_NAME: Wenn Sie die Cloud TPU-Reservierung verwenden, ist dies die Liste der Labels der Reservierungsressourcen, die beim Erstellen des Knotenpools verwendet werden sollen. Weitere Informationen zum Ausfüllen der RESERVATION_LABEL_VALUES im Feld reservation_affinity finden Sie unter Terraform-Anbieter.
  • spot: Legt den Knotenpool so fest, dass Spot-VMs für die TPU-Knoten verwendet werden. Dies kann nach dem Erstellen des Knotenpools nicht mehr geändert werden. Weitere Informationen finden Sie unter Spot-VMs.
  • flex_start: Legt fest, dass der Knotenpool die Verbrauchsoption flex-start verwendet. Kann nicht auf true gesetzt werden, wenn spot aktiviert ist. Flex-Start wird in GKE-Version 1.33.0-gke.1712000 oder höher unterstützt.

Console

So erstellen Sie einen Knotenpool mit TPUs:

  1. Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

    Zur Seite "Google Kubernetes Engine"

  2. Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.

  3. Klicken Sie auf Knotenpool hinzufügen .

  4. Klicken Sie im Abschnitt Knotenpooldetails das Kästchen Knotenstandorte angeben an.

  5. Wählen Sie die Zone anhand der TPU-Version aus, die Sie verwenden möchten. Informationen dazu, wie Sie eine verfügbare Zone ermitteln, finden Sie unter TPU-Verfügbarkeit in GKE.

  6. Klicken Sie im Navigationsbereich auf Knoten.

  7. Wählen Sie im Abschnitt Maschinenkonfiguration die Option TPUs aus.

  8. Wählen Sie im Drop-down-Menü Serie eine der folgenden Optionen aus:

    • CT3: TPU v3, einzelnes Host-Gerät
    • CT3P: TPU v3, Pod-Slice mit mehreren Hosts
    • CT4P: TPU v4
    • CT5LP: TPU v5e
    • CT5P: TPU v5p
    • CT6E: TPU Trillium (v6e)
  9. Wählen Sie im Drop-down-Menü Maschinentyp den Namen des Computers aus, der für Knoten verwendet werden soll. In der Tabelle TPU-Version auswählen erfahren Sie, wie Sie den Maschinentyp und die TPU-Topologie definieren, mit denen ein TPU-Slice-Knotenpool mit einem einzelnen Host erstellt wird.

  10. Wählen Sie im Drop-down-Menü TPU-Topologie die physische Topologie für das TPU-Slice aus.

  11. Klicken Sie im Dialogfeld Änderungen erforderlich auf Änderungen vornehmen.

  12. Achten Sie darauf, dass als Bootlaufwerktyp entweder Nichtflüchtiger Standardspeicher oder Nichtflüchtiger SSD-Speicher angegeben ist.

  13. Klicken Sie optional das Kästchen Knoten auf Spot-VMs aktivieren an, um Spot-VMs für die Knoten im Knotenpool zu verwenden.

  14. Klicken Sie auf Erstellen.

TPU-Slice-Knotenpool mit mehreren Hosts erstellen

Sie können ein TPU-Slice mit mehreren Hosts über die Google Cloud CLI, Terraform oder die Google Cloud Console erstellen.

gcloud

gcloud container node-pools create POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_ZONES \
    --machine-type=MACHINE_TYPE \
    --tpu-topology=TPU_TOPOLOGY \
    [--num-nodes=NUM_NODES] \
    [--spot \]
    [--flex-start \]
    [--enable-autoscaling \
      --max-nodes MAX_NODES]
    [--reservation-affinity=specific \
    --reservation=RESERVATION_NAME] \
    [--node-labels cloud.google.com/gke-nodepool-group-name=COLLECTION_NAME,cloud.google.com/gke-workload-type=HIGH_AVAILABILITY]
    [--placement-type=COMPACT]

Ersetzen Sie Folgendes:

  • POOL_NAME: Der Name des neuen Knotenpools.
  • LOCATION: Der Name der Zone basierend auf der zu verwendenden TPU-Version. Informationen dazu, wie Sie einen verfügbaren Standort ermitteln, finden Sie unter TPU-Verfügbarkeit in GKE.
  • CLUSTER_NAME ist der Name des Clusters.
  • NODE_ZONES: Die kommagetrennte Liste mit einer oder mehreren Zonen, in denen GKE den Knotenpool erstellt.
  • MACHINE_TYPE: Der Maschinentyp für Knoten. Weitere Informationen zu den verfügbaren Maschinentypen finden Sie unter TPU-Version auswählen.
  • TPU_TOPOLOGY: Die physische Topologie für das TPU-Slice. Das Format der Topologie hängt von der TPU-Version ab. Weitere Informationen zu TPU-Topologien finden Sie in der Tabelle unter Topologie auswählen.

    Weitere Informationen finden Sie unter Topologie.

Optional können Sie auch die folgenden Flags verwenden:

  • NUM_NODES: Die maximale Anzahl von Knoten im Knotenpool. Sie muss null oder das Produkt der in TPU_TOPOLOGY definierten Werte ({A}x{B}x{C}) geteilt durch die Anzahl der Chips in jeder VM sein. Für die Multi-Host-Version von TPU v4 und TPU v5e beträgt die Anzahl der Chips in jeder VM vier. Wenn Ihre TPU_TOPOLOGY also 2x4x4 ist (TPU v4 mit vier Chips in jeder VM), beträgt NUM_NODES 32/4, was 8 entspricht. Wenn Sie dieses Flag weglassen, wird die Anzahl der Knoten anhand der Topologie und des Maschinentyps berechnet und standardmäßig festgelegt.
  • RESERVATION_NAME: Der Name der Reservierung, die GKE beim Erstellen des Knotenpools verwendet. Wenn Sie dieses Flag weglassen, verwendet GKE die verfügbaren TPU-Slice-Knotenpools. Weitere Informationen zu TPU-Reservierungen finden Sie unter TPU-Reservierung.
  • --spot: Legt den Knotenpool so fest, dass Spot-VMs für die TPU-Slice-Knoten verwendet werden. Dies kann nach dem Erstellen des Knotenpools nicht mehr geändert werden. Weitere Informationen finden Sie unter Spot-VMs.
  • --flex-start: Legt den Knotenpool so fest, dass Flex-Start-VMs verwendet werden. Flex-Start-VMs werden mit der Verbrauchsoption flex-start erstellt, die in GKE-Version 1.33.0-gke.1712000 oder höher unterstützt wird.
  • --enable-autoscaling: Knotenpool mit aktiviertem Autoscaling erstellen. Wenn GKE einen TPU-Slice-Knotenpool mit mehreren Hosts skaliert, wird der Knotenpool atomar von null auf die maximale Größe hochskaliert.

    • MAX_NODES: Maximale Größe des Knotenpools. Das Flag --max-nodes ist erforderlich, wenn --enable-autoscaling angegeben ist und dem Produkt aus den in TPU_TOPOLOGY definierten Werten ({A}x{B}x{C}) geteilt durch die Anzahl der Chips in jeder VM entsprechen muss.
  • --node-label=cloud.google.com/gke-nodepool-group-name=COLLECTION_NAME, cloud.google.com/gke-workload-type=HIGH_AVAILABILITY: Gibt GKE, dass der Knotenpool für TPU-Slices mit mehreren Hosts eine Sammlung ist. Verwenden Sie dieses Flag, wenn die folgenden Bedingungen erfüllt sind:

    • Der Knotenpool führt Inferenzarbeitslasten im neuen Knotenpool aus.
    • Der Knotenpool verwendet TPU Trillium.
    • Spot-VMs unterstützen keine Zeitplanung für die Erfassung.

    Weitere Informationen zur Verwaltung der Planung von Sammlungen finden Sie unter Planung von Sammlungen in TPU-Slices mit mehreren Hosts verwalten.

  • --placement-type=COMPACT: Knotenpool mit aktivierter kompakter Platzierung erstellen. Diese Option muss mit dem Flag --tpu-topology verwendet werden. Weitere Informationen finden Sie unter Richtlinie für kompakte Platzierung erstellen und TPU-Topologie.

Terraform

  1. Prüfen Sie, ob Sie Version 4.84.0 oder höher des Anbieters google verwenden.
  2. Fügen Sie Ihrer Terraform-Konfiguration den folgenden Block hinzu:

    resource "google_container_node_pool" "NODE_POOL_RESOURCE_NAME" {
      provider           = google
      project            = PROJECT_ID
      cluster            = CLUSTER_NAME
      name               = POOL_NAME
      location           = CLUSTER_LOCATION
      node_locations     = [NODE_ZONES]
      initial_node_count = NUM_NODES
    
      autoscaling {
        max_node_count = MAX_NODES
        location_policy      = "ANY"
      }
      node_config {
        machine_type = MACHINE_TYPE
        reservation_affinity {
          consume_reservation_type = "SPECIFIC_RESERVATION"
          key = "compute.googleapis.com/reservation-name"
          values = [RESERVATION_LABEL_VALUES]
        }
        spot = true
        flex_start = false
      }
    
      placement_policy {
        type = "COMPACT"
        tpu_topology = TPU_TOPOLOGY
      }
    }
    

    Ersetzen Sie Folgendes:

    • NODE_POOL_RESOURCE_NAME: Der Name der Knotenpoolressource in der Terraform-Vorlage.
    • PROJECT_ID: Ihre Projekt-ID.
    • CLUSTER_NAME: Der Name des vorhandenen Clusters, dem der Knotenpool hinzugefügt werden soll.
    • POOL_NAME: Der Name des Knotenpools, der erstellt werden soll.
    • CLUSTER_LOCATION: Der Compute-Standort des Clusters. Wir empfehlen einen regionalen Cluster für eine höhere Zuverlässigkeit der Kubernetes-Steuerungsebene. Sie können auch einen zonalen Cluster verwenden. Weitere Informationen finden Sie unter TPU-Version und Topologie auswählen.
    • NODE_ZONES: Die durch Kommas getrennte Liste mit einer oder mehreren Zonen, in denen GKE den Knotenpool erstellt.
    • NUM_NODES: Die maximale Anzahl von Knoten im Knotenpool. Sie muss null oder das Produkt der Anzahl der TPU-Chips geteilt durch vier sein, da in TPU-Slices mit mehreren Hosts jeder TPU-Slice-Knoten vier Chips hat. Wenn TPU_TOPOLOGY beispielsweise 4x8 ist, gibt es 32 Chips, d. h., NUM_NODES muss 8 sein. Weitere Informationen zu TPU-Topologien finden Sie in der Tabelle unter TPU-Version auswählen.
    • TPU_TOPOLOGY: Dies gibt die gewünschte physische Topologie für das TPU-Slice an. Das Format der Topologie hängt von der verwendeten TPU-Version ab. Weitere Informationen zu TPU-Topologien finden Sie in der Tabelle unter Topologie auswählen.

    Optional können Sie auch die folgenden Variablen verwenden:

    • RESERVATION_NAME: Wenn Sie die TPU-Reservierung verwenden, ist dies die Liste der Labels der Reservierungsressourcen, die beim Erstellen des Knotenpools verwendet werden sollen. Weitere Informationen zum Ausfüllen der RESERVATION_LABEL_VALUES im Feld reservation_affinity finden Sie unter Terraform-Anbieter.
    • autoscaling: Knotenpool mit aktiviertem Autoscaling erstellen. Wenn GKE einen TPU-Slice-Knotenpool mit mehreren Hosts skaliert, wird der Knotenpool atomar von null auf die maximale Größe hochskaliert.
      • MAX_NODES: Die maximale Größe des Knotenpools. Sie muss gleich dem Produkt aus den Werten in TPU_TOPOLOGY definierten Werte ({A}x{B}x{C}) geteilt durch die Anzahl der Chips in jeder VM sein.
    • spot: Ermöglicht dem Knotenpool, Spot-VMs für die TPU-Slice-Knoten zu verwenden. Dies kann nach dem Erstellen des Knotenpools nicht mehr geändert werden. Weitere Informationen finden Sie unter Spot-VMs.
    • flex_start: Legt fest, dass der Knotenpool die Verbrauchsoption flex-start verwendet. Kann nicht auf true gesetzt werden, wenn spot aktiviert ist.

Console

So erstellen Sie einen Knotenpool mit TPUs:

  1. Öffnen Sie in der Google Cloud Console die Seite Google Kubernetes Engine.

    Zur Seite "Google Kubernetes Engine"

  2. Klicken Sie in der Clusterliste auf den Namen des Clusters, den Sie ändern möchten.

  3. Klicken Sie auf Knotenpool hinzufügen .

  4. Klicken Sie im Abschnitt Knotenpooldetails das Kästchen Knotenstandorte angeben an.

  5. Wählen Sie den Namen der Zone basierend auf der TPU-Version aus, die Sie verwenden möchten. Informationen dazu, wie Sie einen verfügbaren Standort ermitteln, finden Sie unter TPU-Verfügbarkeit in GKE.

  6. Klicken Sie im Navigationsbereich auf Knoten.

  7. Wählen Sie im Abschnitt Maschinenkonfiguration die Option TPUs aus.

  8. Wählen Sie im Drop-down-Menü Serie eine der folgenden Optionen aus:

    • CT3P: Für TPU v3.
    • CT4P: Für TPU v4.
    • CT5LP: Für TPU v5e.
  9. Wählen Sie im Drop-down-Menü Maschinentyp den Namen des Computers aus, der für Knoten verwendet werden soll. In der Tabelle TPU-Version auswählen erfahren Sie, wie Sie den Maschinentyp und die TPU-Topologie definieren, mit denen ein TPU-Slice-Knotenpool mit mehreren Hosts erstellt wird.

  10. Wählen Sie im Drop-down-Menü TPU-Topologie die physische Topologie für das TPU-Slice aus.

  11. Klicken Sie im Dialogfeld Änderungen erforderlich auf Änderungen vornehmen.

  12. Achten Sie darauf, dass als Bootlaufwerktyp entweder Nichtflüchtiger Standardspeicher oder Nichtflüchtiger SSD-Speicher angegeben ist.

  13. Klicken Sie optional das Kästchen Knoten auf Spot-VMs aktivieren an, um Spot-VMs für die Knoten im Knotenpool zu verwenden.

  14. Klicken Sie auf Erstellen.

Umgang von GKE mit Kapazitätsproblemen

Wenn GKE den Knotenpool des TPU-Slices aufgrund unzureichender TPU-Kapazität nicht erstellen kann, gibt GKE eine Fehlermeldung zurück, die besagt, dass die Knoten des TPU-Slices aufgrund von Kapazitätsmangel nicht erstellt werden können.

Wenn Sie einen TPU-Slice-Knotenpool mit nur einem Host erstellen, sieht die Fehlermeldung in etwa so aus:

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

Wenn Sie einen TPU-Slice-Knotenpool mit mehreren Hosts erstellen, sieht die Fehlermeldung in etwa so aus:

The nodes (managed by ...) cannot be created now due to lack of capacity. They
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.

Ihre TPU-Bereitstellungsanfrage kann über einen längeren Zeitraum in der Warteschlange verbleiben, wo sie den Status „Wird bereitgestellt“ hat.

Sobald Kapazität verfügbar ist, erstellt GKE die Knoten, die noch nicht erstellt wurden.

Wenn Sie die Kapazität früher benötigen, können Sie Spot-VMs verwenden. Beachten Sie jedoch, dass Spot-VMs ein anderes Kontingent aufnehmen als On-Demand-Instanzen.

Sie können die in die Warteschlange gestellte TPU-Anfrage löschen, indem Sie den TPU-Slice-Knotenpool löschen.

Arbeitslast auf TPU-Slice-Knoten ausführen

In diesem Abschnitt wird beschrieben, wie Sie Ihre Arbeitslasten vorbereiten und wie Sie sie ausführen können.

Arbeitslasten vorbereiten

Für TPU-Arbeitslasten gelten die folgenden Vorbereitungsanforderungen.

  1. Frameworks wie JAX, PyTorch und TensorFlow greifen auf TPU-VMs mit der freigegebenen Bibliothek libtpu zu. libtpu enthält den XLA-Compiler, die TPU-Laufzeitsoftware und den TPU-Treiber. Jede Version von PyTorch und JAX erfordert eine bestimmte Version von libtpu.so. Um Konflikte bei Paketversionen zu vermeiden, empfehlen wir die Verwendung eines JAX AI-Images. Für die Verwendung von TPUs in GKE benötigen Sie die folgenden Versionen:
    TPU-Typ libtpu.so-Version
    TPU Trillium (v6e)
    tpu-v6e-slice
    TPU v5e
    tpu-v5-lite-podslice
    TPU v5p
    tpu-v5p-slice
    TPU v4
    tpu-v4-podslice
    TPU v3
    tpu-v3-slice
    tpu-v3-device
  2. Legen Sie die folgenden Umgebungsvariablen für den Container fest, der die TPU-Ressourcen anfordert:
    • TPU_WORKER_ID: Eine eindeutige Ganzzahl für jeden Pod. Diese ID bezeichnet eine eindeutige Worker-ID im TPU-Slice. Die unterstützten Werte für dieses Feld reichen von null bis zur Anzahl der Pods minus eins.
    • TPU_WORKER_HOSTNAMES: Eine durch Kommas getrennte Liste von TPU-VM-Hostnamen oder IP-Adressen, die innerhalb des Slices miteinander kommunizieren müssen. Für jede TPU-VM im Slice sollte ein Hostname oder eine IP-Adresse vorhanden sein. Die Liste der IP-Adressen oder Hostnamen ist geordnet und ab null nach der TPU_WORKER_ID indexiert.
    • GKE fügt diese Umgebungsvariablen automatisch ein. Dazu wird ein mutierender Webhook verwendet, wenn ein Job mit completionMode: Indexed, subdomain, parallelism > 1 erstellt wird, und es werden google.com/tpu-Attribute angefordert. GKE fügt einen monitorlosen Service hinzu, sodass die DNS-Einträge für die Pods, die den Service unterstützen, hinzugefügt werden.

      Wenn Sie Ressourcen von TPU mit mehreren Hosts mit Kuberay bereitstellen, stellt GKE im Rahmen der experimentellen Terraform-Vorlagen einen bereitstellbaren Webhook zum Ausführen von Ray in GKE bereit. Eine Anleitung zum Ausführen von Ray in GKE mit TPUs finden Sie im experimentellen TPU-Nutzerhandbuch. Der mutierende Webhook schleust diese Umgebungsvariablen in Ray-Cluster ein, die google.com/tpu-Attribute und einen cloud.google.com/gke-tpu-topology-Knotenselektor für mehrere Hosts anfordern.

    • Fügen Sie in Ihrem Arbeitslastmanifest ein Kubernetes-Knotenselektor hinzu, um dafür zu sorgen, dass GKE Ihre TPU-Arbeitslast auf dem von Ihnen definierten TPU-Maschinentyp und der TPU-Topologie plant:

        nodeSelector:
          cloud.google.com/gke-tpu-accelerator: TPU_ACCELERATOR
          cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY
        

      Ersetzen Sie Folgendes:

      • TPU_ACCELERATOR: Der Name des TPU-Beschleunigers.
      • TPU_TOPOLOGY: Die physische Topologie für das TPU-Slice. Das Format der Topologie hängt von der TPU-Version ab. Weitere Informationen finden Sie unter TPUs in GKE planen.

Nachdem Sie die Arbeitslastvorbereitung abgeschlossen haben, können Sie einen Job ausführen, der TPUs verwendet.

Die folgenden Abschnitte zeigen Beispiele für die Ausführung eines Jobs, der eine einfache Berechnung mit TPUs ausführt.

Beispiel 1: Arbeitslast ausführen, die die Anzahl der verfügbaren TPU-Chips in einem TPU-Slice-Knotenpool anzeigt

Die folgende Arbeitslast gibt die Anzahl der TPU-Chips für alle Knoten in einem TPU-Slice mit mehreren Hosts zurück. Zum Erstellen eines Slices mit mehreren Hosts hat die Arbeitslast die folgenden Parameter:

  • TPU-Version: TPU v4
  • Topologie: 2x2x4

Diese Versions- und Topologieauswahl führt zu einem Slice mit mehreren Hosts.

  1. Speichern Sie das folgende Manifest als available-chips-multihost.yaml:
    apiVersion: v1
    kind: Service
    metadata:
      name: headless-svc
    spec:
      clusterIP: None
      selector:
        job-name: tpu-available-chips
    ---
    apiVersion: batch/v1
    kind: Job
    metadata:
      name: tpu-available-chips
    spec:
      backoffLimit: 0
      completions: 4
      parallelism: 4
      completionMode: Indexed
      template:
        spec:
          subdomain: headless-svc
          restartPolicy: Never
          nodeSelector:
            cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice # Node selector to target TPU v4 slice nodes.
            cloud.google.com/gke-tpu-topology: 2x2x4 # Specifies the physical topology for the TPU slice.
          containers:
          - name: tpu-job
            image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
            ports:
            - containerPort: 8471 # Default port using which TPU VMs communicate
            - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
            securityContext:
              privileged: true # Required for GKE versions earlier than 1.28 to access TPUs.
            command:
            - bash
            - -c
            - |
              python -c 'import jax; print("TPU cores:", jax.device_count())' # Python command to count available TPU chips.
            resources:
              requests:
                cpu: 10
                memory: 407Gi
                google.com/tpu: 4 # Request 4 TPU chips for this workload.
              limits:
                cpu: 10
                memory: 407Gi
                google.com/tpu: 4 # Limit to 4 TPU chips for this workload.
  2. Stellen Sie das Manifest bereit:
    kubectl create -f available-chips-multihost.yaml
    

    GKE führt ein TPU v4-Slice mit vier VMs aus (TPU-Slice mit mehreren Hosts). Das Slice hat 16 miteinander verbundene TPU-Chips.

  3. Prüfen Sie, ob der Job vier Pods erstellt hat:
    kubectl get pods
    

    Die Ausgabe sieht in etwa so aus:

    NAME                       READY   STATUS      RESTARTS   AGE
    tpu-job-podslice-0-5cd8r   0/1     Completed   0          97s
    tpu-job-podslice-1-lqqxt   0/1     Completed   0          97s
    tpu-job-podslice-2-f6kwh   0/1     Completed   0          97s
    tpu-job-podslice-3-m8b5c   0/1     Completed   0          97s
    
  4. Rufen Sie die Logs eines der Pods ab:
    kubectl logs POD_NAME
    

    Ersetzen Sie POD_NAME durch den Namen eines der erstellten Pods. Beispiel: tpu-job-podslice-0-5cd8r.

    Die Ausgabe sieht etwa so aus:

    TPU cores: 16
    
  5. Optional: Arbeitslast entfernen:
    kubectl delete -f available-chips-multihost.yaml
    

Beispiel 2: Arbeitslast ausführen, die die Anzahl der verfügbaren TPU-Chips im TPU-Slice anzeigt

Die folgende Arbeitslast ist ein statischer Pod, der die Anzahl der TPU-Chips anzeigt, die mit einem bestimmten Knoten verbunden sind. Zum Erstellen eines Knotens mit einem einzelnen Host hat die Arbeitslast folgende Parameter:

  • TPU-Version: TPU v5e
  • Topologie: 2x4

Diese Versions- und Topologieauswahl führt zu einem Slice mit einem einzelnen Host.

  1. Speichern Sie das folgende Manifest als available-chips-singlehost.yaml:
    apiVersion: v1
    kind: Pod
    metadata:
      name: tpu-job-jax-v5
    spec:
      restartPolicy: Never
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice # Node selector to target TPU v5e slice nodes.
        cloud.google.com/gke-tpu-topology: 2x4 # Specify the physical topology for the TPU slice.
      containers:
      - name: tpu-job
        image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
        ports:
        - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
        securityContext:
          privileged: true # Required for GKE versions earlier than 1.28 to access TPUs.
        command:
        - bash
        - -c
        - |
          python -c 'import jax; print("Total TPU chips:", jax.device_count())'
        resources:
          requests:
            google.com/tpu: 8 # Request 8 TPU chips for this container.
          limits:
            google.com/tpu: 8 # Limit to 8 TPU chips for this container.
  2. Stellen Sie das Manifest bereit:
    kubectl create -f available-chips-singlehost.yaml
    

    GKE stellt Knoten mit acht TPU-Slices mit einem einzelnen Host bereit, die TPU v5e verwenden. Jeder TPU-Knoten hat acht TPU-Chips (TPU-Slice mit einzelnem Host).

  3. Rufen Sie die Logs des Pods ab:
    kubectl logs tpu-job-jax-v5
    

    Die Ausgabe sieht etwa so aus:

    Total TPU chips: 8
    
  4. Optional: Arbeitslast entfernen:
      kubectl delete -f available-chips-singlehost.yaml
      

Knotenpools mit Beschleunigern (GPUs und TPUs) aktualisieren

GKE aktualisiert automatisch Standardcluster, einschließlich Knotenpools. Sie können Knotenpools auch manuell aktualisieren, wenn Sie die Knoten früher auf eine neuere Version aktualisieren möchten. Um die Funktionsweise von Upgrades für Ihren Cluster zu steuern, verwenden Sie Release-Versionen, Wartungsfenster und -ausschlüsse und Roll-out-Sequenzierung.

Sie können auch eine Strategie für Knotenupgrades für Ihren Knotenpool konfigurieren, z. B. Surge-Upgrades, Blau/Grün-Upgrades oder Upgrades mit kurzer Lebensdauer. Durch die Konfiguration dieser Strategien können Sie dafür sorgen, dass die Knotenpools so aktualisiert werden, dass das optimale Gleichgewicht zwischen Geschwindigkeit und Unterbrechung für Ihre Umgebung erreicht wird. Bei TPU-Slice-Knotenpools mit mehreren Hosts erstellt GKE den gesamten Knotenpool atomar in einem einzigen Schritt neu anstelle die konfigurierten Strategie für Knotenupgrades zu verwenden. Weitere Informationen finden Sie in der Definition der Atomarität unter Terminologie in Bezug auf TPU in GKE.

Wenn Sie eine Knotenupgrade-Strategie verwenden, muss GKE je nach Konfiguration vorübergehend zusätzliche Ressourcen bereitstellen. Wenn Google Clouddie Kapazität für die Ressourcen Ihres Knotenpools begrenzt hat, z. B. wenn beim Versuch, mehr Knoten mit GPUs oder TPUs zu erstellen, Fehler zur Ressourcenverfügbarkeit angezeigt werden, finden Sie weitere Informationen unter Upgrade in einer ressourcenbeschränkten Umgebung durchführen.

Bereinigen

Damit Ihrem Google Cloud -Konto die in dieser Anleitung verwendeten Ressourcen nicht in Rechnung gestellt werden, sollten Sie die TPU-Slice-Knotenpools löschen, die keine geplanten Arbeitslasten mehr haben. Wenn die ausgeführten Arbeitslasten ordnungsgemäß beendet werden müssen, verwenden Sie kubectl drain, um die Arbeitslasten zu bereinigen, bevor Sie den Knoten löschen.

  1. Löschen Sie einen TPU-Slice-Knotenpool:

    gcloud container node-pools delete POOL_NAME \
        --location=LOCATION \
        --cluster=CLUSTER_NAME
    

    Ersetzen Sie Folgendes:

    • POOL_NAME: Der Name des Knotenpools.
    • CLUSTER_NAME: Der Name des Clusters.
    • LOCATION: Der Compute-Standort des Clusters.

Zusätzliche Einstellungen konfigurieren

In den folgenden Abschnitten werden die zusätzlichen Konfigurationen beschrieben, die Sie auf Ihre TPU-Arbeitslasten anwenden können.

Planung von Sammlungen verwalten

In TPU Trillium können Sie die Planung von Sammlungen verwenden, um TPU-Slice-Knoten zu gruppieren. Durch das Gruppieren dieser TPU-Slice-Knoten lässt sich die Anzahl der Replikate leichter an die Arbeitslastanforderungen anpassen. Google Cloud steuert Softwareupdates, um dafür zu sorgen, dass immer genügend Slices in der Sammlung verfügbar sind, um Traffic zu verarbeiten.

TPU Trillium unterstützt die Planung von Sammlungen für Knotenpools mit einem einzelnen Host und mehreren Hosts, auf denen Inferenz-Arbeitslasten ausgeführt werden. Im Folgenden wird beschrieben, wie sich die Planung von Sammlungen je nach verwendetem TPU-Slice-Typ verhält:

  • TPU-Slice mit mehreren Hosts:GKE gruppiert TPU-Slices mit mehreren Hosts zu einer Sammlung. Jeder GKE-Knotenpool ist ein Replikat in dieser Sammlung. Wenn Sie eine Sammlung definieren möchten, erstellen Sie einen TPU-Slice mit mehreren Hosts und weisen Sie der Sammlung einen eindeutigen Namen zu. Wenn Sie der Sammlung weitere TPU-Slices hinzufügen möchten, erstellen Sie einen weiteren TPU-Slice-Knotenpool mit mehreren Hosts mit demselben Sammlungsnamen und Arbeitslasttyp.
  • TPU-Slice mit einem Host:GKE betrachtet den gesamten TPU-Slice-Knotenpool mit einem Host als Sammlung. Wenn Sie der Sammlung weitere TPU-Slices hinzufügen möchten, können Sie die Größe des TPU-Slice-Knotenpools mit einem Host ändern.

Wenn Sie eine Sammlung verwalten möchten, führen Sie je nach verwendetem Knotentyp eine der folgenden Aktionen aus.

Sammlungsscheduling in TPU-Slice-Knotenpools mit mehreren Hosts verwalten

Verwenden Sie die folgenden Aufgaben, um TPU-Slice-Knotenpools mit mehreren Hosts zu verwalten.

  • Führen Sie den folgenden Befehl aus, um zu prüfen, ob ein TPU-Slice-Pool mit mehreren Hosts Teil einer Sammlung ist:

    gcloud container node-pools describe NODE_POOL_NAME \
        --location LOCATION \
        --cluster CLUSTER_NAME \
        --format="json" | jq -r \
        '"nodepool-group-name: \(.config.labels["cloud.google.com/gke-nodepool-group-name"] // "")\ngke-workload-type: \(.config.labels["cloud.google.com/gke-workload-type"] // "")"'
    

    Die Ausgabe sieht etwa so aus:

    nodepool-group-name: <code><var>NODE_POOL_COLLECTION_NAME</var></code>
    gke-workload-type: HIGH_AVAILABILITY
    

    Wenn der Pool mit TPU-Slices mit mehreren Hosts Teil einer Sammlung ist, enthält die Ausgabe die folgenden Labels:

    • cloud.google.com/gke-workload-type: HIGH_AVAILABILITY
    • cloud.google.com/gke-nodepool-group-name: <code><var>COLLECTION_NAME</var></code>
  • Führen Sie den folgenden Befehl aus, um die Liste der Sammlungen im Cluster abzurufen:

    #!/bin/bash
    
    # Replace with your cluster name, project, and location
    CLUSTER_NAME=CLUSTER_NAME
    PROJECT=PROJECT_ID
    LOCATION=LOCATION
    
    declare -A collection_names
    
    node_pools=$(gcloud container node-pools list --cluster "$CLUSTER_NAME" --project "$PROJECT" --location "$LOCATION" --format="value(name)")
    
    # Iterate over each node pool
    for pool in $node_pools; do
        # Describe the node pool and extract labels using jq
        collection_name=$(gcloud container node-pools describe "$pool" \
            --cluster "$CLUSTER_NAME" \
            --project "$PROJECT" \
            --location "$LOCATION" \
            --format="json" | jq -r '.config.labels["cloud.google.com/gke-nodepool-group-name"]')
    
        # Add the collection name to the associative array if it's not empty
        if [[ -n "$collection_name" ]]; then
            collection_names["$collection_name"]=1
        fi
    done
    
    # Print the unique node pool collection names
    echo "Unique cloud.google.com/gke-nodepool-group-name values:"
    for name in "${!collection_names[@]}"; do
        echo "$name"
    done
    

    Die Ausgabe sieht etwa so aus:

    Unique cloud.google.com/gke-nodepool-group-name values: {COLLECTION_NAME_1}, {COLLECTION_NAME_2}, {COLLECTION_NAME_3}
    
  • Führen Sie den folgenden Befehl aus, um eine Liste der Knotenpools abzurufen, die zu einer Sammlung gehören:

    #!/bin/bash
    
    TARGET_COLLECTION_NAME=COLLECTION_NAME
    CLUSTER_NAME=CLUSTER_NAME
    PROJECT=PROJECT_ID
    LOCATION=LOCATION
    
    matching_node_pools=()
    
    # Get the list of all node pools in the cluster
    node_pools=$(gcloud container node-pools list --cluster "$CLUSTER_NAME" --project "$PROJECT" --location "$LOCATION" --format="value(name)")
    
    # Iterate over each node pool
    for pool in $node_pools; do
        # Get the value of the cloud.google.com/gke-nodepool-group-name label
        collection_name=$(gcloud container node-pools describe "$pool" \
            --cluster "$CLUSTER_NAME" \
            --project "$PROJECT" \
            --location "$LOCATION" \
            --format="json" | jq -r '.config.labels["cloud.google.com/gke-nodepool-group-name"]')
    
        # Check if the group name matches the target value
        if [[ "$collection_name" == "$TARGET_COLLECTION_NAME" ]]; then
            matching_node_pools+=("$pool")
        fi
    done
    
    # Print the list of matching node pools
    echo "Node pools with collection name '$TARGET_COLLECTION_NAME':"
    for pool in "${matching_node_pools[@]}"; do
        echo "$pool"
    done
    

    Die Ausgabe sieht etwa so aus:

    Node pools with collection name 'COLLECTION_NAME':
    {NODE_POOL_NAME_1}
    {NODE_POOL_NAME_2}
    {NODE_POOL_NAME_3}
    
  • Wenn Sie die Erfassung skalieren möchten, erstellen Sie einen weiteren TPU-Slice-Knotenpool mit mehreren Hosts und fügen Sie cloud.google.com/gke-workload-type und cloud.google.com/gke-nodepool-group-name hinzu. Verwenden Sie denselben Sammlungsnamen in cloud.google.com/gke-nodepool-group-name und führen Sie denselben Workload-Typ aus. Wenn die automatische Knotenbereitstellung für den Cluster aktiviert ist, erstellt GKE automatisch Pools basierend auf den Anforderungen der Arbeitslast.

  • Wenn Sie die Sammlung herunterskalieren möchten, löschen Sie den Knotenpool.

  • Entfernen Sie alle angehängten Knotenpools, um die Sammlung zu löschen. Sie können den Knotenpool löschen oder den Cluster löschen. Wenn Sie den Cluster löschen, werden alle Sammlungen darin entfernt.

Sammlungsplanung in TPU-Slice-Knotenpools mit einem Host verwalten

Verwenden Sie die folgenden Aufgaben, um TPU-Slice-Knotenpools mit einem Host zu verwalten.

  • Führen Sie den folgenden Befehl aus, um zu prüfen, ob für einen TPU-Slice-Pool mit einem einzelnen Host die Sammlung geplant ist:

    gcloud container node-pools describe NODE_POOL_NAME \
        --cluster CLUSTER_NAME \
        --project PROJECT_NAME \
        --location LOCATION \
        --format="json" | jq -r '.config.labels["cloud.google.com/gke-workload-type"]'
    

    Die Ausgabe sieht etwa so aus:

    gke-workload-type: HIGH_AVAILABILITY
    

    Wenn der TPU-Slice-Pool mit einem einzelnen Host Teil einer Sammlung ist, enthält die Ausgabe das Label cloud.google.com/gke-workload-type: HIGH_AVAILABILITY.

  • Wenn Sie die Erfassung skalieren möchten, passen Sie die Größe des Knotenpools manuell oder automatisch mit der automatischen Knotenbereitstellung an.

  • Wenn Sie die Sammlung herunterskalieren möchten, löschen Sie den Knotenpool.

  • Entfernen Sie alle angehängten Knotenpools, um die Sammlung zu löschen. Sie können den Knotenpool löschen oder den Cluster löschen. Wenn Sie den Cluster löschen, werden alle Sammlungen darin entfernt.

Multislice verwenden

Sie können kleinere Slices in einem Multi-Slice aggregieren, um größere Trainingsarbeitslasten zu verarbeiten. Weitere Informationen finden Sie unter Multi-Slice-TPUs in GKE.

TPU-Reservierung migrieren

Wenn Sie bereits TPU-Reservierungen haben, müssen Sie zuerst Ihre TPU-Reservierung zu einem neuen Compute Engine-basierten Reservierungssystem migrieren. Sie können auch ein Compute Engine-basiertes Reservierungssystem erstellen, bei dem keine Migration erforderlich ist. Informationen zum Migrieren Ihrer TPU-Reservierungen finden Sie unter TPU-Reservierung.

Logging aktivieren

Logs, die von Containern ausgegeben werden, die auf GKE-Knoten ausgeführt werden, einschließlich TPU-VMs, werden vom GKE-Logging-Agent erfasst und an Logging gesendet und sind in Logging sichtbar.

Automatische Bereitstellung von GKE-Knoten verwenden

Sie können GKE so konfigurieren, dass Knotenpools automatisch erstellt und gelöscht werden, um die Ressourcenanforderungen Ihrer TPU-Arbeitslasten zu erfüllen. Weitere Informationen finden Sie unter Cloud TPUs konfigurieren.

TPUs mit benutzerdefinierten Compute-Klassen bereitstellen

Sie können GKE auch so konfigurieren, dass TPUs bei Skalierungsvorgängen angefordert werden, bei denen neue Knoten erstellt werden. Verwenden Sie dazu benutzerdefinierte Compute-Klassen.

Sie können TPU-Konfigurationsoptionen in der Spezifikation Ihrer benutzerdefinierten Compute-Klasse angeben. Wenn eine GKE-Arbeitslast diese benutzerdefinierte Compute-Klasse verwendet, versucht GKE, beim Hochskalieren TPUs mit der von Ihnen angegebenen Konfiguration bereitzustellen.

So stellen Sie TPUs mit einer benutzerdefinierten Compute-Klasse bereit, die den TPU-Regeln entspricht, und stellen die Arbeitslast bereit:

  1. Speichern Sie das folgende Manifest als tpu-compute-class.yaml:

    apiVersion: cloud.google.com/v1
    kind: ComputeClass
    metadata:
      name: tpu-class
    spec:
      priorities:
      - tpu:
          type: tpu-v5-lite-podslice
          count: 4
          topology: 2x4
      - spot: true
        tpu:
          type: tpu-v5-lite-podslice
          count: 4
          topology: 2x4
      - flexStart:
          enabled: true
        tpu:
          type: tpu-v6e-slice
          count: 4
          topology: 2x4
      nodePoolAutoCreation:
        enabled: true
    
  2. Stellen Sie die Compute-Klasse bereit:

    kubectl apply -f tpu-compute-class.yaml
    

    Weitere Informationen zu benutzerdefinierten Compute-Klassen und TPUs finden Sie unter TPU-Konfiguration.

  3. Speichern Sie das folgende Manifest als tpu-job.yaml:

    apiVersion: v1
    kind: Service
    metadata:
      name: headless-svc
    spec:
      clusterIP: None
      selector:
        job-name: tpu-job
    ---
    apiVersion: batch/v1
    kind: Job
    metadata:
      name: tpu-job
    spec:
      backoffLimit: 0
      completions: 4
      parallelism: 4
      completionMode: Indexed
      template:
        spec:
          subdomain: headless-svc
          restartPolicy: Never
          nodeSelector:
            cloud.google.com/compute-class: tpu-class
          containers:
          - name: tpu-job
            image: us-docker.pkg.dev/cloud-tpu-images/jax-ai-image/tpu:latest
            ports:
            - containerPort: 8471 # Default port using which TPU VMs communicate
            - containerPort: 8431 # Port to export TPU runtime metrics, if supported.
            command:
            - bash
            - -c
            - |
              python -c 'import jax; print("TPU cores:", jax.device_count())'
            resources:
              requests:
                cpu: 10
                memory: MEMORY_SIZE
                google.com/tpu: NUMBER_OF_CHIPS
              limits:
                cpu: 10
                memory: MEMORY_SIZE
                google.com/tpu: NUMBER_OF_CHIPS
    

    Ersetzen Sie Folgendes:

    • NUMBER_OF_CHIPS: Die Anzahl der TPU-Chips, die für den Container verwendet werden sollen. Muss für limits und requests derselbe Wert sein, der dem Wert im Feld tpu.count in der ausgewählten benutzerdefinierten Compute-Klasse entspricht.
    • MEMORY_SIZE: Die maximale Menge an Speicher, die von der TPU verwendet wird. Die Arbeitsspeicherlimits hängen von der verwendeten TPU-Version und ‑Topologie ab. Weitere Informationen finden Sie unter Mindest- und Höchstwerte für Beschleuniger.
    • NUMBER_OF_CHIPS: Die Anzahl der TPU-Chips, die für den Container verwendet werden sollen. Muss für limits und requests derselbe Wert sein.
  4. Stellen Sie den Job bereit:

    kubectl create -f tpu-job.yaml
    

    Wenn Sie diesen Job erstellen, führt GKE automatisch die folgenden Schritte aus:

    • Stellt Knoten bereit, auf denen die Pods ausgeführt werden. Je nach TPU-Typ, Topologie und Ressourcenanforderungen, die Sie angegeben haben, sind diese Knoten entweder Slices mit einem Host oder Slices mit mehreren Hosts. Je nach Verfügbarkeit von TPU-Ressourcen mit der höchsten Priorität kann GKE auf niedrigere Prioritäten zurückgreifen, um die Verfügbarkeit zu maximieren.
    • Fügt den Pods Markierungen und den Knoten Toleranzen hinzu, um zu verhindern, dass andere Arbeitslasten auf denselben Knoten wie TPU-Arbeitslasten ausgeführt werden.

    Weitere Informationen zu benutzerdefinierten Compute-Klassen

  5. Nach Abschluss dieses Abschnitts können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen:

    kubectl delete -f tpu-job.yaml
    

Automatische Reparatur für TPU-Slice-Knoten konfigurieren

Wenn ein TPU-Slice-Knoten in einem TPU-Slice-Knotenpool mit mehreren Hosts fehlerhaft ist, wird der gesamte Knotenpool neu erstellt. In einem TPU-Slice-Knotenpool mit einem einzelnen Host wird nur der fehlerhafte TPU-Knoten automatisch repariert.

Zu den Elementen, die zu fehlerhaften TPU-Slice-Knoten führen, gehören:

  • TPU-Slice-Knoten mit gängigen Knotenbedingungen.
  • TPU-Slice-Knoten mit einer nicht zuweisbaren TPU-Anzahl größer als null.
  • VM-Instanz in einem TPU-Slice, die aufgrund eines vorzeitigen Beendens angehalten oder anderweitig beendet wurde.
  • Knotenwartung: Wenn ein TPU-Slice-Knoten in einem TPU-Slice-Knotenpool mit mehreren Hosts für die Hostwartung beendet wird, erstellt GKE den gesamten TPU-Slice-Knotenpool neu.

Der Reparaturstatus (einschließlich des Fehlergrundes) wird im Vorgangsverlauf angezeigt. Wenn der Fehler durch ein unzureichendes Kontingent verursacht wird, wenden Sie sich an IhrenGoogle Cloud -Kundenbetreuer, um das entsprechende Kontingent zu erhöhen.

Ordnungsgemäße Beendigung für TPU-Slice-Knoten konfigurieren

In GKE-Clustern mit der Steuerungsebene, auf der 1.29.1-gke.1425000 oder höher ausgeführt wird, unterstützen TPU-Slice-Knoten SIGTERM-Signale, die den Knoten über ein bevorstehendes Herunterfahren informieren. Die Benachrichtigung über das bevorstehende Herunterfahren kann in TPU-Knoten auf bis zu fünf Minuten konfiguriert werden.

Wenn Sie GKE so konfigurieren möchten, dass Ihre Arbeitslasten innerhalb dieses Benachrichtigungszeitraums ordnungsgemäß beendet werden, folgen Sie der Anleitung unter GKE-Knotenunterbrechungen für GPUs und TPUs verwalten.

Container ohne privilegierten Modus ausführen

Für Container, die in Knoten in GKE-Version 1.28 oder höher ausgeführt werden, muss der privilegierte Modus für den Zugriff auf TPUs nicht aktiviert sein. Für Knoten in GKE-Version 1.28 und früher ist der privilegierte Modus erforderlich.

Wenn auf Ihrem TPU-Slice-Knoten Versionen vor 1.28 ausgeführt werden, lesen Sie den folgenden Abschnitt:

Ein Container, der auf einer VM in einem TPU-Slice ausgeführt wird, benötigt Zugriff auf höhere Limits für gesperrten Arbeitsspeicher, damit der Treiber mit den TPU-Chips über DMA (Direct Memory Access) kommunizieren kann. Damit dies möglich ist, müssen Sie ein höheres ulimit konfigurieren. Führen Sie die folgenden Schritte aus, um den Berechtigungsbereich für Ihren Container zu reduzieren:

  1. Bearbeiten Sie securityContext so, dass die folgenden Felder enthalten sind:

    securityContext:
      capabilities:
        add: ["SYS_RESOURCE"]
    
  2. Erhöhen Sie ulimit, indem Sie den folgenden Befehl im Container ausführen, bevor Sie die Arbeitslasten für die Verwendung von TPU-Ressourcen einrichten:

    ulimit -l 68719476736
    

Bei TPU v5e ist die Ausführung von Containern ohne privilegierten Modus in Clustern in Version 1.27.4-gke.900 und höher verfügbar.

Beobachtbarkeit und Messwerte

Dashboard

Die Beobachtbarkeit von Knotenpools in der Google Cloud Console ist allgemein verfügbar. Wenn Sie den Status Ihrer TPU-Knotenpools mit mehreren Hosts in GKE aufrufen möchten, rufen Sie das von Cloud Monitoring bereitgestellte Dashboard GKE TPU Node Pool Status auf:

Zum GKE TPU-Knotenpoolstatus

Dieses Dashboard bietet umfassende Informationen zum Zustand Ihrer TPU-Knotenpools mit mehreren Hosts. Weitere Informationen finden Sie unter Zustandsmesswerte für TPU-Knoten und ‑Knotenpools überwachen.

Auf der Seite Kubernetes-Cluster in derGoogle Cloud Console werden auf dem Tab Beobachtbarkeit auch TPU-Beobachtbarkeitsmesswerte wie die TPU-Nutzung unter der Überschrift Beschleuniger > TPU angezeigt. Weitere Informationen finden Sie unter Beobachtbarkeitsmesswerte aufrufen.

Das TPU-Dashboard wird nur ausgefüllt, wenn in Ihrem GKE-Cluster Systemmesswerte aktiviert sind.

Laufzeitmesswerte

In GKE-Version 1.27.4-gke.900 oder höher exportieren TPU-Arbeitslasten, die sowohl JAX-Version 0.4.14 oder höher verwenden als auch containerPort: 8431 angeben, TPU-Auslastungsmesswerte als GKE-Systemmesswerte. Die folgenden Messwerte sind in Cloud Monitoring verfügbar, um die Laufzeitleistung Ihrer TPU-Arbeitslast zu überwachen:

  • Arbeitszyklus: Prozentsatz der Zeit im vergangenen Stichprobenzeitraum (60 Sekunden), während der TensorCores auf einem TPU-Chip aktiv mit Verarbeitung beschäftigt waren. Ein höherer Prozentsatz bedeutet eine bessere TPU-Auslastung.
  • Arbeitsspeichernutzung: Menge des dem Beschleuniger zugeteilten Arbeitsspeichers in Byte. Alle 60 Sekunden wird eine Stichprobe erstellt.
  • Speicherkapazität: Gesamter Arbeitsspeicher des Beschleunigers in Byte. Alle 60 Sekunden wird eine Stichprobe erstellt.

Diese Messwerte befinden sich im Kubernetes-Knotenschema (k8s_node) und im Kubernetes-Containerschema (k8s_container).

Kubernetes-Container:

  • kubernetes.io/container/accelerator/duty_cycle
  • kubernetes.io/container/accelerator/memory_used
  • kubernetes.io/container/accelerator/memory_total

Kubernetes-Knoten:

  • kubernetes.io/node/accelerator/duty_cycle
  • kubernetes.io/node/accelerator/memory_used
  • kubernetes.io/node/accelerator/memory_total

Messwerte zum Zustand von TPU-Knoten und ‑Knotenpools überwachen

Wenn bei einem Trainingsjob ein Fehler auftritt oder er fehlschlägt, können Sie die Messwerte der zugrunde liegenden Infrastruktur prüfen, um festzustellen, ob die Unterbrechung durch ein Problem mit dem zugrunde liegenden Knoten oder Knotenpool verursacht wurde.

Knotenstatus

In GKE-Version 1.32.1-gke.1357001 oder höher wird der Zustand eines GKE-Knotens durch den folgenden GKE-Systemmesswert dargestellt:

  • kubernetes.io/node/status_condition

Im Feld condition werden Bedingungen für den Knoten gemeldet, z. B. Ready, DiskPressure und MemoryPressure. Im Feld status wird der gemeldete Status der Bedingung angezeigt, der True, False oder Unknown sein kann. Dies ist ein Messwert mit dem überwachten Ressourcentyp k8s_node.

Diese PromQL-Abfrage zeigt, ob ein bestimmter Knoten Ready ist:

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    node_name="NODE_NAME",
    condition="Ready",
    status="True"}

Um Probleme in einem Cluster zu beheben, können Sie sich Knoten ansehen, die andere Bedingungen aufweisen:

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    condition!="Ready",
    status="True"}

Möglicherweise möchten Sie sich speziell Knoten ansehen, die nicht Ready sind:

kubernetes_io:node_status_condition{
    monitored_resource="k8s_node",
    cluster_name="CLUSTER_NAME",
    condition="Ready",
    status="False"}

Wenn keine Daten vorhanden sind, sind die Knoten bereit. Der Status wird alle 60 Sekunden erfasst.

Mit der folgenden Abfrage können Sie den Knotenstatus in der gesamten Flotte ermitteln:

avg by (condition,status)(
  avg_over_time(
    kubernetes_io:node_status_condition{monitored_resource="k8s_node"}[${__interval}]))

Knotenpoolstatus

Der folgende GKE-Systemmesswert für die überwachte Ressource k8s_node_pool gibt den Status eines GKE-Knotenpools an:

  • kubernetes.io/node_pool/status

Dieser Messwert wird nur für Multi-Host-TPU-Knotenpools angegeben.

Im Feld status wird der Status des Knotenpools angegeben, z. B. Provisioning, Running, Error, Reconciling oder Stopping. Statusaktualisierungen erfolgen nach Abschluss der GKE API-Vorgänge.

Mit der folgenden PromQL-Abfrage können Sie prüfen, ob ein bestimmter Knotenpool den Status Running hat:

kubernetes_io:node_pool_status{
    monitored_resource="k8s_node_pool",
    cluster_name="CLUSTER_NAME",
    node_pool_name="NODE_POOL_NAME",
    status="Running"}

Verwenden Sie die folgende PromQL-Abfrage, um die Anzahl der Knotenpools in Ihrem Projekt nach Status gruppiert zu überwachen:

count by (status)(
  count_over_time(
    kubernetes_io:node_pool_status{monitored_resource="k8s_node_pool"}[${__interval}]))

Knotenpoolverfügbarkeit

Der folgende GKE-Systemmesswert gibt an, ob ein TPU-Knotenpool mit mehreren Hosts verfügbar ist:

  • kubernetes.io/node_pool/multi_host/available

Der Messwert hat den Wert True, wenn alle Knoten im Knotenpool verfügbar sind, andernfalls False. Der Messwert wird alle 60 Sekunden abgerufen.

Verwenden Sie die folgende PromQL-Abfrage, um die Verfügbarkeit von TPU-Knotenpools mit mehreren Hosts in Ihrem Projekt zu prüfen:

avg by (node_pool_name)(
  avg_over_time(
    kubernetes_io:node_pool_multi_host_available{
      monitored_resource="k8s_node_pool",
      cluster_name="CLUSTER_NAME"}[${__interval}]))

Anzahl der Knotenunterbrechungen

Der folgende GKE-Systemmesswert gibt die Anzahl der Unterbrechungen für einen GKE-Knoten seit der letzten Stichprobe an (der Messwert wird alle 60 Sekunden abgerufen):

  • kubernetes.io/node/interruption_count

Die Felder interruption_type (z. B. TerminationEvent, MaintenanceEvent oder PreemptionEvent) und interruption_reason (z. B. HostError, Eviction oder AutoRepair) können Aufschluss darüber geben, warum ein Knoten unterbrochen wurde.

Wenn Sie eine Aufschlüsselung der Unterbrechungen und ihrer Ursachen in TPU-Knoten in den Clustern in Ihrem Projekt erhalten möchten, verwenden Sie die folgende PromQL-Abfrage:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[${__interval}]))

Wenn Sie nur die Hostwartungsereignisse sehen möchten, aktualisieren Sie die Abfrage, um den HW/SW Maintenance-Wert für interruption_reason zu filtern. Verwenden Sie die folgende PromQL-Abfrage:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))

Verwenden Sie die folgende PromQL-Abfrage, um die Anzahl der Unterbrechungen nach Knotenpool zusammenzufassen:

  sum by (node_pool_name,interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))

Wiederherstellungszeiten (Time To Recover, TTR) des Knotenpools

Der folgende GKE-Systemmesswert gibt die Verteilung der Dauer des Wiederherstellungszeitraums für GKE-TPU-Knotenpools mit mehreren Hosts an:

  • kubernetes.io/node_pool/accelerator/times_to_recover

Jede in diesem Messwert aufgezeichnete Stichprobe gibt ein einzelnes Wiederherstellungsereignis für den Knotenpool nach einer Ausfallzeit an.

Dieser Messwert ist nützlich, um die Wiederherstellungszeit und die Zeit zwischen Unterbrechungen von Multi-Host-TPU-Knotenpools zu verfolgen.

Mit der folgenden PromQL-Abfrage können Sie die mittlere Zeit bis zur Wiederherstellung (Mean Time to Recovery, MTTR) für die letzten 7 Tage in Ihrem Cluster berechnen:

sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_to_recover_sum{
    monitored_resource="k8s_node_pool", cluster_name="CLUSTER_NAME"}[7d]))
/
sum(sum_over_time(
  kubernetes_io:node_pool_accelerator_times_to_recover_count{
    monitored_resource="k8s_node_pool",cluster_name="CLUSTER_NAME"}[7d]))

Zeiten zwischen Unterbrechungen (Times Between Interruptions, TBI) des Knotenpools

Die Zeit zwischen Unterbrechungen des Knotenpools gibt an, wie lange Ihre Infrastruktur läuft, bevor es zu einer Unterbrechung kommt. Er wird als Durchschnitt über einen bestimmten Zeitraum berechnet. Der Zähler gibt die Gesamtzeit an, in der Ihre Infrastruktur verfügbar war, und der Nenner die Gesamtzahl der Unterbrechungen Ihrer Infrastruktur.

Das folgende PromQL-Beispiel zeigt die durchschnittliche Zeit zwischen Unterbrechungen (Mean Time Between Interruptions, MTBI) für den angegebenen Cluster über einen Zeitraum von sieben Tagen:

sum(count_over_time(
  kubernetes_io:node_memory_total_bytes{
    monitored_resource="k8s_node", node_name=~"gke-tpu.*|gk3-tpu.*", cluster_name="CLUSTER_NAME"}[7d]))
/
sum(sum_over_time(
  kubernetes_io:node_interruption_count{
    monitored_resource="k8s_node", node_name=~"gke-tpu.*|gk3-tpu.*", cluster_name="CLUSTER_NAME"}[7d]))

Hostmesswerte

In GKE-Version 1.28.1-gke.1066000 oder höher exportieren VMs in einem TPU-Slice TPU-Auslastungsmesswerte als GKE-Systemmesswerte. Die folgenden Messwerte sind in Cloud Monitoring verfügbar, um die Leistung Ihres TPU-Hosts zu überwachen:

  • TensorCore-Auslastung: Aktueller Prozentsatz des verwendeten TensorCore. Der TensorCore-Wert entspricht der Summe der Matrixmultiplikationseinheiten (MXUs) plus der Vektoreinheit. Der TensorCore-Auslastungswert ist der Quotient aus den TensorCore-Vorgängen, die im letzten Stichprobenzeitraum (60 Sekunden) ausgeführt wurden, und der unterstützten Anzahl von TensorCore-Vorgängen im selben Zeitraum. Ein größerer Wert bedeutet eine bessere Auslastung.
  • Auslastung der Arbeitsspeicherbandbreite: Aktueller Prozentsatz der verwendeten Arbeitsspeicherbandbreite des Beschleunigers. Wird berechnet, indem die in einem Stichprobenzeitraum (60 s) verwendete Arbeitsspeicherbandbreite durch die maximal unterstützte Bandbreite im selben Stichprobenzeitraum geteilt wird.

Diese Messwerte befinden sich im Kubernetes-Knotenschema (k8s_node) und im Kubernetes-Containerschema (k8s_container).

Kubernetes-Container:

  • kubernetes.io/container/accelerator/tensorcore_utilization
  • kubernetes.io/container/accelerator/memory_bandwidth_utilization

Kubernetes-Knoten:

  • kubernetes.io/node/accelerator/tensorcore_utilization
  • kubernetes.io/node/accelerator/memory_bandwidth_utilization

Weitere Informationen finden Sie unter Kubernetes-Messwerte und GKE-Systemmesswerte.

Bekannte Probleme

  • Cluster Autoscaler kann die Kapazität für neue TPU-Slice-Knoten falsch berechnen, bevor diese Knoten die verfügbaren TPUs melden. Cluster-Autoscaler kann dann zusätzliche Hochskalierungen ausführen und so mehr Knoten als erforderlich erstellen. Cluster Autoscaler skaliert zusätzliche Knoten nach dem regulären Herunterskalieren herunter, wenn sie nicht benötigt werden.
  • Cluster Autoscaler bricht das Hochskalieren von TPU-Slice-Knotenpools ab, die länger als 10 Stunden im Wartestatus verbleiben. Cluster Autoscaler wiederholt solche Hochskalierungsversuche später. Dieses Verhalten kann die TPU-Erreichbarkeit für Kunden reduzieren, die keine Reservierungen verwenden.
  • Nicht-TPU-Arbeitslasten mit einer Toleranz für die TPU-Markierung können das Herunterskalieren des Knotenpools verhindern, wenn sie während des Leerens des TPU-Slice-Knotenpools neu erstellt werden.
  • Der Messwert „Auslastung der Arbeitsspeicherbandbreite“ ist für v5e-TPUs nicht verfügbar.

Nächste Schritte