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 Trainieren von umfangreichen Deep-Learning-Modellen. 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 wir in Google Cloud Inhalten verweisen, 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 dafür sorgen, dass Sie genügend Kontingent haben, wenn Sie TPUs in GKE verwenden.

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
      Ironwood (TPU7x) (Vorschau),
      tpu7x-standard-4t 
      Dimensions (e.g. location):
      tpu_family:tpu7x
      		 
      Name:
      Preemptible TPU slices tpu7x

    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-Kontingenterhöhung 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.

Cluster erstellen

Sie können einen Cluster erstellen, der TPUs verwendet, indem Sie die Google Cloud CLI oder ein Accelerated Processing Kit (XPK) verwenden.

  • Mit der Google Cloud CLI können Sie Ihre GKE-Clusterinstanz manuell erstellen, um vorhandene GKE-Produktionsumgebungen präzise anzupassen oder zu erweitern.
  • Mit XPK können Sie schnell GKE-Cluster erstellen und Arbeitslasten für Konzeptnachweise und Tests ausführen. Weitere Informationen und Anleitungen finden Sie in der README-Datei für XPK.

Im folgenden Dokument wird beschrieben, wie Sie TPUs mit der Google Cloud CLI konfigurieren.

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.

TPUs bereitstellen

Für die Bereitstellung von TPUs in GKE haben Sie die folgenden Konfigurationsoptionen:
  • Knotenpool manuell erstellen: Sie können einen Knotenpool mit einer bestimmten TPU-Version und -Topologie erstellen.
  • Automatische Knotenbereitstellung in GKE verwenden: Sie können die automatische Knotenbereitstellung auf Clusterebene aktivieren und dann in Ihrem Pod-Manifest mit einem nodeSelector die TPU-Version und -Topologie angeben. Wenn ein ausstehender Pod mit diesen Selektoren übereinstimmt, erstellt GKE automatisch einen neuen Knotenpool, der die Anfrage erfüllt. Bei dieser Methode müssen Sie Ressourcenlimits auf Clusterebene für TPUs festlegen.
  • Benutzerdefinierte Compute-Klassen definieren: Sie können TPUs mit benutzerdefinierten Compute-Klassen anfordern. Mit benutzerdefinierten ComputeClasses 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.

Knotenpool manuell 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 durch Kommas getrennte Liste mit einer oder mehreren Zonen, in denen GKE den Knotenpool erstellt.
  • MACHINE_TYPE: die TPU-Version und der Typ. Verwenden Sie beispielsweise tpu7x-standard-4t für Ironwood (TPU7x).

Optional können Sie auch die folgenden Flags verwenden:

  • --num-nodes=NUM_NODES: Die anfängliche Anzahl von Knoten im Knotenpool in jeder Zone.

    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 zum Verwalten der Planung von Sammlungen finden Sie unter Planung von Sammlungen 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. Weitere Informationen finden Sie unter Arbeitslast mit kleinem Batch mit TPUs und Flex-Start-VMs ausführen.

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

Die Schritte zum Erstellen eines TPU-Slice-Knotenpools mit mehreren Hosts unterscheiden sich je nachdem, ob Sie Ironwood (TPU7x) oder eine frühere TPU-Version verwenden.

Ironwood (TPU7x)

Sie können einen TPU-Slice-Knotenpool mit mehreren Hosts in der Version „Ironwood“ (TPU7x) über die Google Cloud CLI oder Terraform erstellen:

gcloud

Wenn Sie einen TPU-Slice-Knotenpool mit mehreren Hosts mit Ironwood (TPU7x) erstellen möchten, müssen Sie zuerst eine Arbeitslastrichtlinie erstellen.

  1. Arbeitslastrichtlinie erstellen:

    gcloud compute resource-policies create workload-policy WORKLOAD_POLICY_NAME \
    --type=HIGH_THROUGHPUT \
    --accelerator-topology=TPU_TOPOLOGY \
    --project=PROJECT_ID \
    --region=REGION

    Ersetzen Sie Folgendes:

    • WORKLOAD_POLICY_NAME: ein Name für Ihre Arbeitslastrichtlinie.
    • TPU_TOPOLOGY: Die TPU-Ironwood-Topologie (TPU7x). Beispiel: 2x2x2. Eine Liste aller unterstützten Ironwood-Topologien (TPU7x) finden Sie im Abschnitt zu Topologien.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • REGION: die Region für die Arbeitslastrichtlinie. Eine Arbeitslastrichtlinie ist eine regionale Ressource und kann für Knotenpools wiederverwendet werden, die dieselbe Topologie haben.

  2. Erstellen Sie den Knotenpool mit der Arbeitslastrichtlinie:

    gcloud container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --machine-type=tpu7x-standard-4t \
  --placement-policy=WORKLOAD_POLICY_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --node-locations=NODE_ZONE \
  --project=PROJECT_ID \
  --reservation=RESERVATION_NAME \
  --reservation-affinity=specific

    Ersetzen Sie Folgendes:

    • NODE_POOL_NAME: Der Name des neuen Knotenpools.
    • CLUSTER_NAME: der Name Ihres GKE-Clusters.
    • WORKLOAD_POLICY_NAME: der Name der von Ihnen erstellten Workload-Richtlinie.
    • CONTROL_PLANE_LOCATION: Der Compute Engine-Standort der Steuerungsebene des Clusters. Geben Sie für regionale Cluster eine Region und für zonale Cluster eine Zone an.
    • NODE_ZONE: 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.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • RESERVATION_NAME: Der Name der Reservierung, die verwendet werden soll.

    In diesem Befehl wurde das Flag --tpu-topology durch das Flag --placement-policy ersetzt.

Terraform

  1. Prüfen Sie, ob Sie Version 4.84.0 oder höher des Anbieters google verwenden.

  2. Arbeitslastrichtlinie erstellen:

    resource "google_compute_resource_policy" {
  name   = "WORKLOAD_POLICY_NAME"
  region = CLUSTER_LOCATION
  workload_policy {
    type = "HIGH_THROUGHPUT"
    accelerator_topology = "TPU_TOPOLOGY"
  }
}

    Ersetzen Sie Folgendes:

    • WORKLOAD_POLICY_NAME: ein Name für Ihre Arbeitslastrichtlinie.
    • 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.
    • TPU_TOPOLOGY: Die TPU-Ironwood-Topologie (TPU7x). Beispiel: 2x2x2. Alle unterstützten Ironwood-Topologien (TPU7x) finden Sie unter TPUs planen.

    Weitere Informationen zur google_compute_resource_policy-Referenz finden Sie unter Terraform-Anbieter.

  3. 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]
    }
    flex_start = false
    spot = true
  }

  placement_policy {
    policy_name = WORKLOAD_POLICY_NAME
  }
}

    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.
    • NODE_ZONES: Die durch Kommas getrennte Liste mit einer oder mehreren Zonen, in denen GKE den Knotenpool erstellt.
    • NUM_NODES: Die Anzahl der 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 ausgewählte 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 eine TPU-Reservierung verwenden, geben Sie eine Liste der Labels der Reservierungsressourcen an, 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. Der Wert muss gleich dem Produkt aus den in TPU_TOPOLOGY definierten Werten ({A}x{B}x{C}) geteilt durch die Anzahl der Chips in jeder VM sein. Wenn TPU_TOPOLOGY beispielsweise 2x2x2 ist, ist das Produkt 8. Da jede VM in tpu7x-standard-4t 4 Chips hat, beträgt die Anzahl der Knoten 2.
    • spot: Der Knotenpool, der Spot-VMs für die TPU-Slice-Knoten verwendet. Diese Einstellung kann nach dem Erstellen des Knotenpools nicht mehr geändert werden. Weitere Informationen finden Sie unter Spot-VMs.
    • flex_start: Der Knotenpool, für den die Verbrauchsoption flex-start verwendet wird. Diese Einstellung kann nicht auf true gesetzt werden, wenn spot aktiviert ist.

Andere TPU-Versionen

Sie können einen Knotenpool für ein TPU-Slice mit mehreren Hosts in Version v3, v4, v5p, v5e und Trillium (v6e) über die Google Cloud CLI, Terraform oder die Google Cloud Console erstellen.

gcloud

  gcloud container node-pools create POOL_NAME \
      --location=CONTROL_PLANE_LOCATION \
      --cluster=CLUSTER_NAME \
      --node-locations=NODE_ZONE \
      --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.
  • CONTROL_PLANE_LOCATION: der Compute Engine-Standort der Steuerungsebene Ihres Clusters. Geben Sie für regionale Cluster eine Region und für zonale Cluster eine Zone an.
  • CLUSTER_NAME ist der Name des Clusters.
  • NODE_ZONES: 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.
  • 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 Anzahl der 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: Die 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 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]
    }
    flex_start = false
    spot = true
  }

  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 Anzahl der 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 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 in TPU_TOPOLOGY definierten Werten ({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:

    • CT3: TPU v3, Gerät mit einem Host
    • 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 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.

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.

  1. Wenn Sie die automatische Bereitstellung von Knotenpools aktivieren möchten, bearbeiten Sie die TPU-Ressourcenlimits Ihres Clusters:

      gcloud container clusters update CLUSTER_NAME \
      --location=CONTROL_PLANE_LOCATION \
      --enable-autoprovisioning \
      --min-cpu=MINIMUM_CPU \
      --min-memory=MINIMUM_MEMORY \
      --max-cpu=MAXIMUM_CPU \
      --max-memory=MAXIMUM_MEMORY \
      --min-accelerator=type=TPU_TYPE,count=MINIMUM_TPU_COUNT \
      --max-accelerator=type=TPU_TYPE,count=MAXIMUM_TPU_COUNT

    Ersetzen Sie Folgendes:

    • TPU_TYPE: der TPU-Typ. Verwenden Sie beispielsweise tpu7x-standard-4t für Ironwood (TPU7x).
    • MINIMUM_TPU_COUNT: die Mindestanzahl von TPU-Chips des angegebenen Typs, die der Cluster haben kann. Wenn der von Ihnen angegebene Wert größer als die Anzahl der TPU-Chips in einem TPU-Slice mit mehreren Hosts ist, entfernt GKE alle Knoten im Slice. Knotenpools mit mehreren Hosts werden zwischen 0 und der Anzahl der Knoten im Slice skaliert. Es gibt keine Zwischenwerte.
    • MAXIMUM_TPU_COUNT: die maximale Anzahl von TPU-Chips des angegebenen Typs, die der Cluster haben kann. Geben Sie für TPU-Slices mit mehreren Hosts einen Wert an, der größer als die Anzahl der Chips in jedem Slice ist, damit GKE den Slice atomar skalieren kann. Die Anzahl der Chips in einem Slice ist das Produkt der TPU-Topologie. Wenn die Topologie beispielsweise 2x2x2 ist, beträgt die Anzahl der Chips im Slice 8. Das bedeutet, dass der Wert von MAXIMUM_TPU_COUNT größer als 8 sein muss.

Benutzerdefinierte Compute-Klassen definieren

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 Ihrer benutzerdefinierten ComputeClass-Spezifikation angeben. Wenn eine GKE-Arbeitslast diese benutzerdefinierte ComputeClass verwendet, versucht GKE, beim Hochskalieren TPUs mit der von Ihnen angegebenen Konfiguration bereitzustellen.

In den folgenden Abschnitten erfahren Sie, wie Sie eine benutzerdefinierte Compute-Klasse erstellen und dann einen Job erstellen, der die in der Compute-Klasse definierten TPUs verwendet.

Benutzerdefinierte Compute-Klasse erstellen

Die Schritte zum Erstellen einer benutzerdefinierten ComputeClass, die den TPU-Regeln entspricht, hängen davon ab, ob Sie Ironwood (TPU7x) oder eine frühere TPU-Version verwenden.

Ironwood (TPU7x)

  1. Arbeitslastrichtlinie erstellen Dieser Schritt ist nur erforderlich, wenn Sie einen Knotenpool mit mehreren Hosts erstellen. Das hängt von der von Ihnen ausgewählten Topologie ab. Wenn Sie einen Knotenpool mit einem einzelnen Host verwenden, überspringen Sie diesen Schritt.

    gcloud compute resource-policies create workload-policy WORKLOAD_POLICY_NAME \
    --type=HIGH_THROUGHPUT \
    --accelerator-topology=TPU_TOPOLOGY \
    --project=PROJECT_ID \
    --region=REGION

    Ersetzen Sie Folgendes:

    • WORKLOAD_POLICY_NAME: ein Name für Ihre Arbeitslastrichtlinie.
    • TPU_TOPOLOGY: Die TPU-Ironwood-Topologie (TPU7x). Verwenden Sie zum Beispiel 2x2x2. Weitere Informationen zu allen unterstützten Ironwood-Topologien (TPU7x) finden Sie im Abschnitt zu Topologien.
    • PROJECT_ID: Ihre Google Cloud Projekt-ID
    • REGION: Die Region für die Workload-Richtlinie. Eine Arbeitslastrichtlinie ist eine regionale Ressource, die Sie in mehreren Knotenpools verwenden können.

  2. 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: tpu7x
        topology: TPU_TOPOLOGY
        count: 4
      placement:
        policyName: WORKLOAD_POLICY_NAME
  nodePoolAutoCreation:
    enabled: true

  3. Optional können Sie eine bestimmte Reservierung oder einen bestimmten Unterblock nutzen. Sie können Ihrem ComputeClass-Manifest beispielsweise das folgende specs hinzufügen:

      reservations:
    affinity: Specific
    specific:
      - name: RESERVATION_NAME
        reservationBlock:
          name: RESERVATION_BLOCK_NAME
          reservationSubBlock:
            name: RESERVATION_SUB_BLOCK_NAME

    Ersetzen Sie Folgendes:

    • RESERVATION_NAME: der Name der Compute Engine-Kapazitätsreservierung.
    • RESERVATION_BLOCK_NAME: Der Name des Compute Engine-Kapazitätsreservierungsblocks.
    • RESERVATION_SUB_BLOCK_NAME: Der Name des Compute Engine-Kapazitätsreservierungsunterblocks.

    Weitere Informationen finden Sie unter Reservierte zonale Ressourcen aufnehmen.

Andere TPU-Versionen

Wenn Sie v3-, v4-, v5p-, v5e- oder v6e-TPUs (Trillium) mit einer benutzerdefinierten ComputeClass konfiguriert für TPUs bereitstellen möchten, führen Sie die folgenden Schritte aus:

  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_TYPE
      count: NUMBER_OF_CHIPS
      topology: TOPOLOGY
  - spot: true
    tpu:
      type: {"<var>"}}TPU_TYPE
      count: NUMBER_OF_CHIPS
      topology: TOPOLOGY
  - flexStart:
      enabled: true
    tpu:
      type: {"<var>"}}TPU_TYPE
      count: NUMBER_OF_CHIPS
      topology: TOPOLOGY
  nodePoolAutoCreation:
    enabled: true

    Ersetzen Sie Folgendes:

    • TPU_TYPE: Der zu verwendende TPU-Typ, z. B. tpu-v4-podslice. Muss ein von GKE unterstützter Wert sein.
    • TOPOLOGY: die Anordnung der TPU-Chips im Slice, z. B. 2x2x4. Muss eine unterstützte Topologie für den ausgewählten TPU-Typ sein.
    • 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.

  2. Stellen Sie die ComputeClass bereit:

    kubectl apply -f tpu-compute-class.yaml

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

Job erstellen, der TPUs verwendet

  1. 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 CHIP_COUNT in der ausgewählten benutzerdefinierten ComputeClass 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.

  2. 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 finden Sie unter Benutzerdefinierte Compute-Klassen.

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

    kubectl delete -f tpu-job.yaml

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 mit 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: tpu7x
    TPU-Typ libtpu.so-Version
    Ironwood (TPU7x) (Vorschau)
    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. 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
    cloud.google.com/placement-policy-name: WORKLOAD_POLICY # Required only for Ironwood (TPU7x)

    Ersetzen Sie Folgendes:

    • TPU_ACCELERATOR: Der Name des TPU-Beschleunigers. Verwenden Sie zum Beispiel tpu7x-standard-4t.
    • TPU_TOPOLOGY: Die physische Topologie für das TPU-Slice. Das Format der Topologie hängt von der TPU-Version ab. Verwenden Sie zum Beispiel 2x2x2. Weitere Informationen finden Sie unter TPUs in GKE planen.
    • WORKLOAD_POLICY: Der Name der Arbeitslastrichtlinie, die Sie zum Platzieren Ihrer TPU-Pods verwenden möchten. Diese Knotenauswahl ist nur für Ironwood (TPU7x) erforderlich.

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.

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.

Beispiel 1: Deployment ausführen, das TPUs in der Pod-Spezifikation anfordert

GKE verwendet die Konfiguration in Ihrem Pod oder Ihrer Compute-Klasse, um die Konfiguration Ihrer TPU-Knoten zu bestimmen. Das folgende Manifest ist ein Beispiel für eine Deployment-Spezifikation, in der TPUs in der Pod-Spezifikation angefordert werden. Wenn die Einstellung für die automatische Knotenbereitstellung auf Clusterebene aktiviert ist, wird durch diese Bereitstellung die automatische Erstellung von Knotenpools ausgelöst. Wenn Sie diese Beispielbereitstellung erstellen, erstellt GKE einen Knotenpool, der einen TPU v4-Slice mit einer 2x2x2-Topologie und zwei ct4p-hightpu-4t-Maschinen enthält.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tpu-workload
  labels:
    app: tpu-workload
spec:
  replicas: 2
  template:
    spec:
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: tpu-v4-podslice
        cloud.google.com/gke-tpu-topology: 2x2x2
      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: 4
          limits:
            google.com/tpu: 4
        ports:
        - containerPort: 80

In diesem Manifest definieren die folgenden Felder die TPU-Konfiguration:

  • cloud.google.com/gke-tpu-accelerator: die TPU-Version und der Typ. Verwenden Sie beispielsweise tpu7x-standard-4t für Ironwood (TPU7x).
  • cloud.google.com/gke-tpu-topology: Die Topologie mit der Anzahl und der physischen Anordnung der TPU-Chips in einem TPU-Slice. Verwenden Sie zum Beispiel 2x2x2.
  • limits.google.com/tpu: die Anzahl der TPU-Chips pro VM. Wenn Sie beispielsweise tpu7x-standard-4t verwenden, beträgt die Anzahl der TPU-Chips pro VM 4.

Beispiel 2: 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 3: 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.

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 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 Systemzustandsmesswerte 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. Das Feld status enthält den gemeldeten Status der Bedingung, 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 Hostwartungen sehen möchten, aktualisieren Sie die Abfrage, um den Wert HW/SW Maintenance nach 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 durchschnittliche 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.

Planung von Sammlungen verwalten

In TPU Trillium können Sie die Planungsoption für 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 Sammlungsplanung für Knotenpools mit einzelnen 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. Um eine Sammlung zu definieren, 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 Multi-Host-TPU-Slice-Pool 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 Sammlung 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.

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