Dynamisches Aufteilen mit einem benutzerdefinierten Scheduler verwenden

In diesem Dokument wird beschrieben, wie Sie dynamisches Slicing verwenden, indem Sie direkt mit benutzerdefinierten Slice-Ressourcen interagieren. Sie können Slices erstellen, Partitionsstatus überwachen und den Zustand von Slices prüfen.

Bevor Sie dieser Anleitung folgen, sollten Sie sich mit den Konzepten des dynamischen Aufteilens vertraut machen.

Vorteile von dynamischem Slicing mit einem benutzerdefinierten Scheduler

Verwenden Sie Ihren eigenen Scheduler, um Slice-Ressourcen zu verwalten, wenn Sie komplexe Planungsanforderungen haben oder dynamisches Slicing in Ihre vorhandene Planungsinfrastruktur einbinden möchten.

Wenn Sie lieber einen Scheduler verwenden möchten, anstatt Slice-benutzerdefinierte Ressourcen direkt zu verwalten, bietet GKE die Integration mit Kueue und Topology Aware Scheduling (TAS). Weitere Informationen finden Sie unter Dynamische Slices mit Kueue und TAS planen.

Übersicht über den Workflow

Wenn Sie dynamisches Slicing mit einem benutzerdefinierten Scheduler verwenden möchten, führen Sie die folgenden Aufgaben in diesem Dokument aus:

  1. Slice-Controller aktivieren
  2. Knotenpools mit inkrementeller Bereitstellung erstellen
  3. Benutzerdefinierte Slice-Ressourcen basierend auf Ihren Arbeitslastanforderungen erstellen. Wenden Sie die benutzerdefinierte Ressource „Slice“ auf Ihren Cluster an.
  4. Partitionsstatus und Slice-Integrität überwachen
  5. Löschen Sie den Ausschnitt, wenn Sie fertig sind.

Weitere Informationen zu den Feldern und dem Status der benutzerdefinierten Slice-Ressource finden Sie in den Referenzinformationen zur benutzerdefinierten Slice-Ressource.

Voraussetzungen

Damit Sie dynamisches Slicing in GKE verwenden können, müssen die folgenden Anforderungen erfüllt sein:

  • Verwenden Sie einen Standardcluster im Rapid Channel in einer der folgenden Versionen:
    • Für die dynamische Konfiguration von Super-Slicing (Topologien, die größer oder gleich 4x4x4 sind) verwenden Sie Version 1.35.2-gke.1842000 oder höher.
    • Für die dynamische Konfiguration von Sub-Slicing (Topologien kleiner als 4x4x4) verwenden Sie Version 1.36.0-gke.3712000 oder höher.
  • Verwenden Sie die Ironwood-Version (TPU7x).
  • Verwenden Sie das Container-Optimized OS-Image für Ihre Knoten.
  • Wenn Sie die inkrementelle Bereitstellung verwenden möchten, müssen Sie Reservierungen im Modus „Alle Kapazitäten“ verwenden. „Alle“-Kapazitätsmodus ist eine Funktion, die von TPU Cluster Director aktiviert wird.
  • Für das dynamische Unterteilen von Slices müssen auf Ihren Knoten ausstehende Wartungsereignisse vorhanden sein. Instanzen auf anstehende Wartungsereignisse überwachen Wenn für einen Ihrer Knoten ein ausstehendes Wartungsereignis mit einem Endzeitpunkt zwischen dem 18. September 2026 und dem 30. September 2026 vorliegt, müssen Sie das Wartungsereignis für den Host für diese Knoten manuell auslösen, bevor Sie die Unterteilung verwenden können.

Hinweis

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

Slice-Controller aktivieren

Wenn Sie dynamisches Slicing verwenden möchten, aktivieren Sie den Slice-Controller in Ihrem Cluster.

  1. Cluster aktualisieren:

    gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --enable-slice-controller

    Ersetzen Sie Folgendes:

  2. Rufen Sie Anmeldedaten ab, damit Sie mit kubectl-Befehlen mit Ihrem Cluster kommunizieren können:

    gcloud config set container/cluster CLUSTER_NAME
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION

  3. Prüfen Sie in der Ausgabe des folgenden Befehls, ob der Wert slices.accelerator.gke.io vorhanden ist:

    kubectl get crd slices.accelerator.gke.io

    Die Ausgabe sieht etwa so aus:

    slices.accelerator.gke.io                2026-01-09T23:58:02Z

Knotenpools mit inkrementeller Bereitstellung erstellen

In diesem Abschnitt wird beschrieben, wie Sie die TPU-Knotenpools mit inkrementeller Bereitstellung erstellen. GKE konvertiert Ihre gesamte TPU-Kapazität in Knotenpools mit einer 16-Knoten-Gruppe von TPU-VMs oder Unterblöcken. GKE stellt diese Knotenpools auch dann bereit, wenn nicht alle 16 fehlerfreien VMs gefunden werden können. Dazu werden Knoten auf fehlerfreien Teilen des Hostcomputers platziert und fehlerhafte Maschinen inkrementell bereitgestellt, während sie repariert werden.

Sie können festlegen, dass Ihr Knotenpool zu einer der folgenden Kategorien gehört:

  • Ein bestimmter TPU-Block, der in Reservierungen im Modus „Alle Kapazitäten“ verfügbar ist. Durch die Blockausrichtung kann GKE den Knotenpool in einem beliebigen verfügbaren Unterblock innerhalb des angegebenen Blocks erstellen.
  • Ein bestimmter Unterblock oder eine bestimmte Gruppe von 16 TPU-VMs für eine detailliertere Steuerung.

Arbeitslastrichtlinie erstellen

Wenn Sie einen TPU-Slice-Knotenpool mit Ironwood (TPU7x) erstellen möchten, müssen Sie zuerst eine Arbeitslastrichtlinie erstellen, bei der das Feld accelerator-topology-mode auf provision_only festgelegt ist. Diese Einstellung löst den inkrementellen Bereitstellungsprozess aus.

Arbeitslastrichtlinie erstellen:

gcloud compute resource-policies create workload-policy WORKLOAD_POLICY_NAME \
        --project=PROJECT_ID \
        --region=REGION  \
        --type=HIGH_THROUGHPUT \
        --accelerator-topology=4x4x4 \
        --accelerator-topology-mode=provision_only

Ersetzen Sie Folgendes:

  • WORKLOAD_POLICY_NAME: ein Name für Ihre Arbeitslastrichtlinie.
  • PROJECT_ID: Projekt-ID in Google Cloud .
  • REGION: die Region für die Arbeitslastrichtlinie.

Führen Sie in diesem Befehl folgende Schritte aus:

  • Legen Sie das Feld accelerator-topology immer auf 4x4x4 fest, damit es der Gesamtzahl der Chips in einem einzelnen Unterblock entspricht.
  • Legen Sie das Feld accelerator-topology-mode immer auf provision_only fest, damit der inkrementelle Bereitstellungsprozess ausgelöst wird. Wenn das Feld provision_only festgelegt ist, werden im Knotenpool TPU-Knoten bereitgestellt, ohne ICI- oder OCS-Verbindungen zu erstellen.

Knotenpool einem Block oder Unterblock zuweisen

Sie können bestimmte Unterblöcke oder Blöcke in Ihrer Reservierung im Modus „Alle Kapazitäten“ targetieren.

  • Auf einen Block ausrichten:Jeder Knotenpool verwendet Kapazität aus einem bestimmten Block. GKE platziert den Knotenpool in einem verfügbaren Unterblock in diesem Block. Sie müssen so viele Knotenpools erstellen, wie es Unterblöcke im Block gibt, den Sie verwenden möchten.

  • Auf einen Unterblock ausrichten:Jeder Knotenpool wird einem bestimmten verfügbaren Unterblock zugeordnet. Wenn Sie die Ausrichtung auf Unterblöcke verwenden, erstellt GKE den Knotenpool, wenn mindestens eine VM fehlerfrei ist. Die inkrementelle Bereitstellung trägt dazu bei, dass alle Knoten innerhalb des angegebenen Unterblocks platziert werden.

Blockieren

  1. Wenn Sie den Namen des Blocks in einer Reservierung und die Anzahl der verfügbaren Unterblöcke im Block abrufen möchten, führen Sie die folgenden Schritte im Dokument Topologie und Status von Reservierungen im Modus „Alle Kapazitäten“ ansehen aus:

    1. Ermitteln Sie den Namen des Blocks, indem Sie alle Reservierungsblöcke auflisten und den Wert im Feld name: kopieren. Dieser Wert ist der Name des Blocks oder BLOCK_NAME in diesem Dokument.

    2. Ermitteln Sie, wie viele Knotenpools erstellt werden sollen, indem Sie einen Reservierungsblock beschreiben und den Wert im Feld reservationSubBlockCount ermitteln. Dieser Wert gibt die Anzahl der verfügbaren Unterblöcke an. Der Wert reservationSubBlockCount: 4 gibt beispielsweise an, dass für den Block vier Unterblöcke verfügbar sind und Sie vier separate Knotenpools erstellen müssen.

  2. Reservierungspfad festlegen:

    export RESERVATION_PATH="projects/PROJECT_ID/reservations/RESERVATION_NAME/reservationBlocks/BLOCK_NAME"

    Ersetzen Sie Folgendes:

    • RESERVATION_NAME: Der Name Ihrer TPU-Reservierung.
    • BLOCK_NAME: der Name des Blocks.

  3. Erstellen Sie für jeden im vorherigen Schritt ermittelten Unterblock einen Knotenpool. Wenn die Anzahl beispielsweise 4 ist, führen Sie diesen Befehl viermal aus. Verwenden Sie für jeden Knotenpool einen eindeutigen Namen.

    gcloud container node-pools create NODE_POOL_NAME \
      --cluster=CLUSTER_NAME \
      --node-locations=ZONE \
      --machine-type=tpu7x-standard-4t \
      --num-nodes=16 \
      --placement-policy=WORKLOAD_POLICY_NAME \
      --reservation-affinity=specific \
      --reservation=${RESERVATION_PATH}

    Ersetzen Sie Folgendes:

    • NODE_POOL_NAME ist der Name des neuen Knotenpools.
    • CLUSTER_NAME: der Name Ihres GKE-Clusters.
    • WORKLOAD_POLICY_NAME: der Name der von Ihnen erstellten Workload-Richtlinie.
    • ZONE: die Zone für den Knotenpool, z. B. us-central1-a.

Unterblock

  1. Führen Sie die folgenden Schritte im Dokument Topologie und Integritätsstatus von Reservierungen im Modus „Alle Kapazitäten“ ansehen aus, um den Namen des Blocks und die IDs der verfügbaren Unterblöcke abzurufen:

    1. Um den Namen des Blocks zu ermitteln, listen Sie alle Reservierungsblöcke auf und kopieren Sie den Wert im Feld name:. Dieser Wert ist der Name des Blocks oder der BLOCK_NAME in diesem Dokument.

    2. Wenn Sie den Namen der Unterblöcke ermitteln möchten, listen Sie alle Unterblöcke eines Blocks auf und kopieren Sie den Wert im Feld name: für jeden Eintrag unter reservationSubBlocks. Dieser Wert ist der Name des Unterblocks oder SUBBLOCK_NAME in diesem Dokument.

  2. Reservierungspfad festlegen:

    export RESERVATION_PATH="projects/PROJECT_ID/reservations/RESERVATION_NAME/reservationBlocks/BLOCK_NAME/reservationSubBlocks/SUBBLOCK_NAME"

    Ersetzen Sie Folgendes:

    • RESERVATION_NAME: Der Name Ihrer TPU-Reservierung.
    • BLOCK_NAME: der Name des Blocks.
    • SUBBLOCK_NAME: der Name des Unterblocks.

  3. Knotenpool erstellen:

    gcloud container node-pools create NODE_POOL_NAME \
        --project=PROJECT_ID \
        --cluster=CLUSTER_NAME \
        --node-locations=ZONE \
        --machine-type=tpu7x-standard-4t \
        --num-nodes=16 \
        --placement-policy=WORKLOAD_POLICY_NAME \
        --reservation-affinity=specific \
        --reservation=${RESERVATION_PATH}

    Ersetzen Sie Folgendes:

    • NODE_POOL_NAME: ein eindeutiger Name für Ihren neuen Knotenpool, z. B. sub-block-pool-1.
    • PROJECT_ID: Projekt-ID in Google Cloud .
    • CLUSTER_NAME: Name Ihres GKE-Clusters.
    • ZONE: Die Zone für den Knotenpool, z. B. us-central2-b.
    • WORKLOAD_POLICY_NAME: der Name der von Ihnen erstellten Arbeitslastrichtlinie.

In dieser Phase werden die Knoten erstellt, ihre Inter-Chip Interconnect-Verbindungen (ICI) sind jedoch noch nicht aktiv. Daher können Sie Arbeitslasten nicht direkt in diesen Knotenpools ausführen.

Damit alle erforderlichen ICI-Links zum Erstellen des Slices und zum Planen von Arbeitslasten verwendet werden können, erstellen Sie einen dynamischen Slice mit einer der folgenden Methoden:

  • Erstellen Sie eine benutzerdefinierte Slice-Ressource. Anstelle von Pods verwenden Sie eine benutzerdefinierte Slice-Ressource, um die angegebene Topologie zu definieren, die vom Slice-Controller aktiviert wird.
  • GKE-Arbeitslasten mit Kueue und TAS planen. Kueue übernimmt automatisch das Erstellen und Löschen von benutzerdefinierten Slice-Ressourcen. Von Kueue erstellte benutzerdefinierte Slice-Ressourcen sollten nicht manuell geändert werden.

Dynamischen Segment mit Super- oder Sub-Slicing erstellen

Nachdem Sie die Knotenpools erstellt haben, können Sie ein größeres dynamisches Super-Slice oder ein kleineres dynamisches Sub-Slice erstellen, indem Sie eine benutzerdefinierte Slice-Ressource erstellen. Eine benutzerdefinierte Slice-Ressource definiert die angegebene Topologie, die vom Slice-Controller aktiviert wird. Ihre Arbeitslasten werden dann in diesem dynamischen Slice geplant und ausgeführt.

Dynamische Segmentpartitionen

Partitionen stellen die Topologien bereit, die zum Erstellen eines dynamischen Slices für Ihre Arbeitslasten verfügbar sind. In einer Partition werden alle verfügbaren Topologien für jeden Knoten angezeigt, einschließlich 2x2x1, 2x2x2, 2x2x4, 2x4x4 und 4x4x4. Für Topologien, die kleiner als 4x4x4 sind, ist die GKE-Version 1.36.0-gke.3712000 oder höher erforderlich.

Für alle Slices, die größer als 4x4x4 sind, gibt es kein Partitionslabel, da sie durch die Verknüpfung mehrerer 4x4x4-Partitionen erstellt werden.

Jeder TPU-Knoten in einem Knotenpool mit inkrementeller Bereitstellung muss alle angegebenen Knotenlabels für Partitions-ID und Partitionsstatus haben.

Status der Knoten und Partitionen prüfen

  1. Führen Sie den folgenden Befehl aus, um die Knotennamen aus dem Knotenpool abzurufen:

    kubectl get nodes -l cloud.google.com/gke-nodepool=${NODE_POOL_NAME}

    Die Ausgabe sieht in etwa so aus:

    NAME                                 STATUS   ROLES    AGE    VERSION
gke-np-status-update-7b4c890c-0jhp   Ready    <none>   2d1h   v1.35.1-gke.1396002
gke-np-status-update-7b4c890c-377r   Ready    <none>   2d1h   v1.35.1-gke.1396002
gke-np-status-update-7b4c890c-gb51   Ready    <none>   2d1h   v1.35.1-gke.1396002

  2. Prüfen Sie das Bereitstellungsmodell des Knotens:

    kubectl describe node NODE_NAME | grep "cloud.google.com/gke-accelerator-topology-mode"

    Die Ausgabe sieht in etwa so aus:

    cloud.google.com/gke-accelerator-topology-mode: PROVISION_ONLY

  3. Rufen Sie die Knotenlabelinformationen für die Topologiepartition ab, auf die Sie abzielen möchten:

    kubectl describe node NODE_NAME | grep -E "cloud.google.com/gke-tpu-partition-.*-id"

    Ersetzen Sie NODE_NAME durch den Namen eines der Knoten im Knotenpool.

    Die Ausgabe sieht in etwa so aus:

    cloud.google.com/gke-tpu-partition-4x4x4-id=fba785f80d18552357dcdef6d3d16c27
cloud.google.com/gke-tpu-partition-2x4x4-id=e18372d627ac412cb24d5ea8ab8912c9
cloud.google.com/gke-tpu-partition-2x2x4-id=7fbd4e29dc1839217fae41a9dd8211b4
cloud.google.com/gke-tpu-partition-2x2x2-id=a9476d1b02bd4f4e75ffffae3bd23c01
cloud.google.com/gke-tpu-partition-2x2x1-id=0bcfe937d1bb3914a8bdcd94e9f73319

  4. Prüfen Sie, ob der Knoten die Annotation node.gke.io/created-by-mig enthält:

    kubectl describe node NODE_NAME | grep "node.gke.io/created-by-mig"

    Ersetzen Sie NODE_NAME durch den Namen eines der Knoten im Knotenpool.

    Die Ausgabe sieht in etwa so aus:

    node.gke.io/created-by-mig: projects/735972712744/zones/us-central1-ai1a/team/string

    Die Ausgabe enthält die Annotation node.gke.io/created-by-mig, mit der die GKE-Steuerungsebene Kubernetes-Knoten mit den zugrunde liegenden Compute Engine-Ressourcen verknüpfen kann.

  5. Rufen Sie die Knotenlabelinformationen für den Topologiepartitionsstatus ab, den Sie überprüfen möchten:

    kubectl describe node NODE_NAME | grep -E "cloud.google.com/gke-tpu-partition-.*-state"

    Die Ausgabe sieht in etwa so aus:

    cloud.google.com/gke-tpu-partition-4x4x4-state=HEALTHY
cloud.google.com/gke-tpu-partition-2x4x4-state=HEALTHY
cloud.google.com/gke-tpu-partition-2x2x4-state=HEALTHY
cloud.google.com/gke-tpu-partition-2x2x2-state=HEALTHY
cloud.google.com/gke-tpu-partition-2x2x1-state=HEALTHY

    Das Label cloud.google.com/gke-tpu-partition-[shape]-state (wobei [shape] der Topologie der Partitions-ID entspricht) gibt an, ob die Partition zum Erstellen eines dynamischen Slices verfügbar ist. Dieses Statuslabel unterstützt die folgenden Werte:

    • HEALTHY: Die Partition ist fehlerfrei und voll funktionsfähig.
    • DEGRADED: Die Partition ist beeinträchtigt, kann aber weiterhin für die dynamische Segmentbildung verwendet werden. Dieser Status gilt nur für die 4x4x4-Topologie der obersten Ebene. Bei kleineren Topologien gibt es keinen eingeschränkten Zustand.
    • UNHEALTHY: Die Partition funktioniert nicht richtig und kann nicht zum Erstellen eines Slice verwendet werden.
    • UNSET: Der Status ist aufgrund einer fehlgeschlagenen Initialisierung des GKE-Slice-Controllers nicht definiert.
    • INCOMPLETE: Nicht alle Knoten in der Partition werden bereitgestellt.

Benutzerdefinierte Slice-Ressource erstellen

Die benutzerdefinierte Ressource „Slice“ variiert geringfügig, je nachdem, ob Sie einen dynamischen Super-Slice oder einen dynamischen Sub-Slice erstellen.

  1. Definieren Sie die benutzerdefinierte Slice-Ressource:

    apiVersion: accelerator.gke.io/v1beta1
kind: Slice
metadata:
  # Name of the slice resource
  name: SLICE_NAME
spec:
  # Specify the type of accelerator for this slice
  type: "tpu7x"
  # Define the desired topology for the accelerator slice
  topology: TOPOLOGY
  partitionIds:
    - PARTITION_ID # Example: a9476d1b02bd4f4e75ffffae3bd23c01
    - PARTITION_ID_2
    # ... add more partition IDs as needed

    Ersetzen Sie Folgendes:

    • SLICE_NAME: ein Name für Ihr Segment. Der Name muss den Bedingungen für metadata.name entsprechen und darf maximal 49 Zeichen lang sein.
    • TOPOLOGY: Die Topologie für das dynamische Slice. Die Topologie muss die folgenden Bedingungen erfüllen:
      • Für dynamisches Unterteilen in Slices können Sie Topologien angeben, die kleiner als 4x4x4 sind, z. B. 2x2x1, 2x2x2, 2x2x4 oder 2x4x4. Für diese kleineren Topologien ist die GKE-Version 1.36.0-gke.3712000 oder höher erforderlich.
      • Für dynamisches Super-Slicing:Sie können Topologien angeben, die gleich oder größer als 4x4x4 sind. Wenn Sie das dynamische Super-Slicing konfigurieren möchten, muss jede Dimension der angeforderten Topologie ein Vielfaches von vier sein, z. B. 4A x 4B x 4C. Die drei Werte in den Topologiedimensionen, AxBxC, müssen in nicht absteigender Reihenfolge angegeben werden (A ≤ B ≤ C). Beispiel: 4x4x8 ist gültig, 4x8x4 jedoch nicht. Diese Reihenfolge sorgt für eine konsistente Segmentbildung und vermeidet unerwartetes Verhalten. Das Produkt der drei Werte in den Topologiedimensionen, A × B × C,darf 9.216 nicht überschreiten.
    • PARTITION_ID: Eine Liste von Strings, die die Partitionen des Segments identifizieren.
      • Für dynamisches Unterteilen in Slices müssen Sie genau eine Partitions-ID angeben.
      • Für dynamisches Super-Slicing müssen Sie die Anzahl der Partitionen anhand der Gesamtzahl der Chips berechnen. Jede Partition besteht aus 64 Chips. Die Anzahl der Elemente in Ihrer spec.partitionIds-Liste muss genau mit der berechneten Anzahl der Partitionen ((A × B × C) / 64) übereinstimmen.
      • Die partitionIds-Liste muss die folgenden Bedingungen erfüllen:
        • Jede Partition muss einem Reservierungsunterblock zugeordnet werden.
        • Alle zugehörigen Unterblöcke müssen zur selben Reservierung gehören.
        • Alle zugehörigen Unterblöcke müssen sich in derselben Reservierung befinden.
        • Die zugehörigen Knotenpools müssen alle Knoten im Status ready haben.
    • Der Wert des Felds type muss tpu7x sein.
    • Optional können Sie der benutzerdefinierten Slice-Ressource die Annotation slice.gke.io/retry-on-failure: "true" hinzufügen, damit der Slice-Controller während der Slice-Erstellung automatisch Wiederholungsversuche unternimmt. Wenn das Segment aufgrund des Statusgrunds SliceCreationFailed nicht erstellt wird, versucht der Controller es noch einmal, bis das Segment erfolgreich erstellt wurde.

    Wenn Sie beispielsweise einen 4x8x8-Slice (dynamisches Super-Slicing) erstellen möchten, müssen Sie vier eindeutige Partitions-IDs angeben.

    apiVersion: accelerator.gke.io/v1beta1
kind: Slice
metadata:
    name: test-super-slice-example
    annotations:
      slice.gke.io/retry-on-failure: "true"
spec:
    type: "tpu7x"
    topology: "4x8x8" # (4*8*8)/64 = 4 partitions
    partitionIds:
        - "p0-4x4x4"
        - "p1-4x4x4"
        - "p2-4x4x4"
        - "p3-4x4x4"

    Wenn Sie beispielsweise einen 2x2x2-Slice (dynamisches Unter-Slicing) erstellen möchten, müssen Sie eine eindeutige Partitions-ID angeben.

    apiVersion: accelerator.gke.io/v1beta1
kind: Slice
metadata:
  name: test-sub-slice-example
  annotations:
      slice.gke.io/retry-on-failure: "true"
spec:
  type: "tpu7x"
  topology: "2x2x2"
  partitionIds:
    - "fba785f80d18552357dcdef6d3d16c27" # Only 1 partitionId for sub-slice

  2. Wenden Sie die benutzerdefinierte Slice-Ressource an:

    kubectl apply -f test-slice-example.yaml

    An diesem Punkt versucht GKE, den Slice zu erstellen. Wenn eines der folgenden Probleme auftritt, schlägt die Erstellung des Slice fehl und der Statusgrund in der benutzerdefinierten Slice-Ressource wird auf SliceCreationFailed oder FAILED aktualisiert:

    • Wenn die ausgewählten Knoten in der benutzerdefinierten Ressource nicht vorhanden sind, lautet der Statusgrund SliceCreationFailed.
    • Wenn Knoten in der benutzerdefinierten Ressource von einem anderen Slice verwendet werden, lautet der Statusgrund SliceCreationFailed.
    • Wenn die Knoten in der benutzerdefinierten Ressource nicht Teil desselben Reservierungsunterblocks sind, lautet der Statusgrund FAILED.
    • Wenn sich die Knoten nicht in derselben Reservierung befinden, lautet der Statusgrund FAILED.
    • Wenn die Topologie nicht mit der Anzahl der Partitionen übereinstimmt, lautet der Statusgrund SliceCreationFailed.

    Wenn die Slice-Erstellung automatisch wiederholt werden soll, wenn der Status SliceCreationFailed ist, konfigurieren Sie die Annotation slice.gke.io/retry-on-failure: "true" wie unter Benutzerdefinierte Slice-Ressource erstellen beschrieben.

    Weitere Informationen zum Status der benutzerdefinierten Ressource „Slice“ finden Sie unter Slice-Status.

Status der benutzerdefinierten Slice-Ressource überwachen

Führen Sie den folgenden Befehl aus, um den Status der benutzerdefinierten Slice-Ressource zu prüfen:

kubectl describe slice SLICE_NAME

Ersetzen Sie SLICE_NAME durch den Namen des Segments.

Die Ausgabe sieht etwa so aus:

Name:         test-slice
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  accelerator.gke.io/v1beta1
Kind:         Slice
Metadata:
  Creation Timestamp:  2026-01-11T23:45:15Z
  Finalizers:
    accelerator.gke.io/slice-finalizer
  Generation:        1
  Resource Version:  1768175347356335006
  UID:               d0b71e5c-be3f-4788-aead-930c7afec4f2
Spec:
  Partition Ids:
    2c79463990ff67c4e3c2648666bfedfa
    ba898ffcac0ad0946e8ff036d771ee53
    [more partition IDs]
  Topology:  8x16x16
  Type:      tpu7x
Status:
  Conditions:
    Last Transition Time:  2026-01-11T23:45:38Z
    Message:               ""
    
    Reason:                FAILED
    
    Status:                False
    Type:                  Ready
Events:

Das Feld reason im Status der benutzerdefinierten Slice-Ressource gibt den aktuellen Lebenszyklusstatus an. Die möglichen Status variieren je nachdem, ob Sie dynamische Unterlizenzen oder dynamische Superlizenzen verwenden.

Statusbedingungen für dynamische Untersegmentierung

  • SliceNotCreated: Der Controller führt die Initialisierung und Ressourcenprüfungen durch.
    • Wenn die Voraussetzungen nicht erfüllt sind, wechselt der Status zu SliceCreationFailed.
    • Wenn die Validierung erfolgreich ist, ändert sich der Status zu ACTIVATING.
  • ACTIVATING: GKE bildet den Slice.
    • Bei Erfolg wechselt der Status zu ACTIVE.
    • Wenn Unterblöcke eingeschränkt sind, der Slice aber verwendet werden kann, ändert sich der Status zu ACTIVE_DEGRADED.
    • Wenn die Bildung fehlschlägt, wechselt der Status zu FAILED.
  • DEACTIVATING: Wenn die benutzerdefinierte Slice-Ressource gelöscht wird oder ein kritischer Fehler in einem aktiven oder fehlgeschlagenen Status auftritt, wird das Slice abgebaut.
  • INCOMPLETE: Der letzte Schritt, bevor die Ressource vollständig gelöscht wird.

Statusbedingungen für dynamisches Super-Slicing

  • SliceNotCreated: Das Segment wurde noch nicht erstellt. Der Slice-Controller wird initialisiert und führt Preflight-Prüfungen für die Slice-Erstellung durch.
  • SliceCreationFailed: Die Erstellung ist fehlgeschlagen, weil die Voraussetzungen nicht erfüllt waren (z. B. erforderliche Compute Engine-Ressourcen fehlen) oder Preflight-Prüfungen fehlgeschlagen sind. Wenn Sie die Segmentbildung in diesem Status automatisch wiederholen möchten, konfigurieren Sie die slice.gke.io/retry-on-failure: "true"-Annotation.
  • ACTIVATING: Das Segment wird gerade erstellt (zusammengefügt).
  • ACTIVE: Der Slice ist vollständig, fehlerfrei und bereit für die Ausführung von Arbeitslasten.
  • ACTIVE_DEGRADED: Der Slice wird gebildet, enthält aber degradierte Cubes, die durch die ICI-Resilienz unterstützt werden. Arbeitslasten können ausgeführt werden, aber die Leistung ist möglicherweise beeinträchtigt. Dynamisches Super-Slicing ist gegenüber dem Ausfall eines einzelnen optischen Schalters (Optical Circuit Switch, OCS) stabil. Wenn eine einzelne OCS-Einheit ausfällt, sind alle optischen Verbindungen, die diesen Switch durchlaufen, nicht mehr verfügbar. Dadurch arbeiten alle Cubes im Superpod in einem eingeschränkten Zustand.
  • DEACTIVATING: Das Segment wird gerade aufgelöst.
  • FAILED: Der Slice kann keine Arbeitslasten mehr ausführen. Dieser Status tritt auf, wenn die anfängliche Bildung fehlgeschlagen ist oder bei einem aktiven Slice ein kritischer Software- oder Hardwarefehler aufgetreten ist.
  • INCOMPLETE: Es sind nicht genügend verfügbare Cubes vorhanden, um die Bildung von Super-Slices zu starten.

Weitere Informationen zum Status der benutzerdefinierten Ressource „Slice“ finden Sie unter Slice-Status.

Arbeitslasten mit dynamischem Slicing ausführen

Wenn sich die benutzerdefinierte Ressource „Slice“ im Status ACTIVE befindet, können Sie Arbeitslasten darauf ausführen. Im folgenden Abschnitt finden Sie Beispiele für Arbeitslasten, bei denen dynamisches Slicing verwendet wird. Die Arbeitslasten werden als Jobs oder JobSets eingereicht.

Beispiel 1: Eine einzelne Arbeitslast verwendet einen einzelnen Slice

Im folgenden Beispiel wird eine Arbeitslast mit einem einzelnen dynamischen 4x4x4-Superslice dargestellt.

  1. Speichern Sie das folgende Beispielmanifest als tpu-job-jax-v7x-64.yaml:

    # Copyright 2026 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    job-name: tpu-job-jax-v7x-64
---
apiVersion: batch/v1
kind: Job
metadata:
  name: tpu-job-jax-v7x-64
spec:
  backoffLimit: 0
  completions: 16
  parallelism: 16
  completionMode: Indexed
  template:
    metadata:
      annotations:
        cloud.google.com/gke-tpu-slice-topology: 4x4x4
    spec:
      nodeSelector:
        cloud.google.com/gke-tpu-topology: 4x4x4
        cloud.google.com/gke-tpu-accelerator: tpu7x
        cloud.google.com/gke-tpu-slice: test-slice
      subdomain: headless-svc
      restartPolicy: Never
      containers:
      - name: tpu-job-jax
        env:
        - name: TPU_ACCELERATOR_TYPE
          value: tpu7x-128
        image: python:3.12
        securityContext:
          privileged: false
        command:
        - bash
        - -c
        - |
          set -ex
          pip install -U --pre jax jaxlib libtpu requests -i https://us-python.pkg.dev/ml-oss-artifacts-published/jax/simple/ -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
          pip list
          python -c 'import jax; print("Total TPU devices (cores):", jax.device_count())'
        resources:
          requests:
            google.com/tpu: 4
          limits:
            google.com/tpu: 4

    In diesem Manifest:

    • cloud.google.com/gke-tpu-slice-topology und cloud.google.com/gke-tpu-topology definieren die Topologie des dynamischen Slice.
    • env.value: tpu7x-128 ist der TPU-Beschleunigertyp und die Gesamtzahl der Kerne im Slice. Die Anzahl der Kerne wird berechnet, indem die Dimensionen der Topologie mit der Anzahl der Kerne pro Chip multipliziert werden. Bei einer 4x4x4-Topologie lautet die Berechnung beispielsweise 4 × 4 × 4 × 2 = 128, wobei 2 die Anzahl der Kerne pro Chip für tpu7x (Ironwood (TPU7x)) ist. Daher ist die TPU_ACCELERATOR_TYPE tpu7x-128.

  2. Wenden Sie das tpu-job-jax-v7x-64.yaml-Manifest an:

    kubectl apply -f tpu-job-jax-v7x-64.yaml

Beispiel 2: Arbeitslast mit JobSet in Multislice-Knotenpools bereitstellen

In diesem Beispiel wird gezeigt, wie Sie eine Arbeitslast mit JobSet in Multislice-Knotenpools bereitstellen.

  1. JobSet installieren:

    kubectl apply --server-side -f https://github.com/kubernetes-sigs/jobset/releases/download/JOBSET_VERSION/manifests.yaml

    Ersetzen Sie JOBSET_VERSION durch die erforderliche Version von JobSet. Für das dynamische Unterteilen von Slices ist JobSet v0.12.0 oder höher erforderlich. Für dynamisches Super-Slicing verwenden Sie JobSet v0.11.1 oder höher.

  2. Speichern Sie das folgende Beispielmanifest als tpu-multislice-jax.yaml:

    # Copyright 2026 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

apiVersion: jobset.x-k8s.io/v1alpha2
kind: JobSet
metadata:
  name: tpu-multislice-jax
  annotations:
    alpha.jobset.sigs.k8s.io/exclusive-topology: cloud.google.com/gke-tpu-slice
spec:
  failurePolicy:
    maxRestarts: 3
  replicatedJobs:
  - name: slice-job
    replicas: 2
    template:
      spec:
        parallelism: 16
        completions: 16
        backoffLimit: 0
        completionMode: Indexed
        template:
          metadata:
            annotations:
              # The shape of the slice
              cloud.google.com/gke-tpu-slice-topology: 4x4x4
          spec:
            hostNetwork: true
            dnsPolicy: ClusterFirstWithHostNet
            nodeSelector:
              cloud.google.com/gke-tpu-topology: 4x4x4
              cloud.google.com/gke-tpu-accelerator: tpu7x
              # IMPORTANT: Do NOT put 'cloud.google.com/gke-tpu-slice' here manually.
              # The exclusive-topology annotation handles the slice assignment automatically.
            containers:
            - name: jax-worker
              image: python:3.12
              securityContext:
                privileged: true
              ports:
              - containerPort: 8471
              command:
              - bash
              - -c
              - |
                set -ex
                pip install -U --pre jax jaxlib libtpu requests -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
                # Verify JobSet injected the specific slice ID for this worker
                echo "JobSet Index: $JOB_COMPLETION_INDEX"
                python -c 'import jax; print("Total TPU devices:", jax.device_count())'
              resources:
                requests:
                  google.com/tpu: 4
                limits:
                  google.com/tpu: 4

  3. Wenden Sie das tpu-multislice-jax.yaml-Manifest an:

    kubectl apply -f tpu-multislice-jax.yaml

    In diesem Manifest:

    • Das Feld replicas: 2 unter replicatedJobs gibt an, dass JobSet zwei separate Jobs erstellt, die jeweils einem 4x4x4-TPU-Slice entsprechen.
    • Die Annotation alpha.jobset.sigs.k8s.io/exclusive-topology: cloud.google.com/gke-tpu-slice sorgt dafür, dass jeder Job einem eindeutigen TPU-Slice zugewiesen wird.
    • Mit der Annotation cloud.google.com/gke-tpu-slice-topology: 4x4x4 wird die Topologie jedes dynamischen Slice definiert.
    • Die Umgebungsvariable TPU_ACCELERATOR_TYPE wird in diesem Beispiel nicht explizit festgelegt, da die Zuweisung von Segmenten von JobSet übernommen wird. Im JAX-Code werden die verfügbaren TPU-Geräte im zugewiesenen Slice automatisch erkannt.

Segment löschen

  1. Löschen Sie den Slice:

    kubectl patch slice $SLICE_NAME --type json \
  -p='[{"op": "remove", "path": "/metadata/finalizers"}]'

  2. Prüfen Sie, ob das Segment gelöscht wurde:

    kubectl get slices

Knotenpools aktualisieren

Wenn Sie Knotenpools aktualisieren, die mit der inkrementellen Bereitstellung konfiguriert sind, müssen Sie bestimmte Surge-Parameter verwenden, um Kapazitätskonflikte zu vermeiden.

So konfigurieren und führen Sie das Knotenpool-Upgrade aus:

  1. Wenn Sie dynamisches Super-Slicing verwenden, löschen Sie Ihre aktiven Slices, bevor Sie die manuelle Wartung ausführen:

    kubectl delete slice SLICE_NAME

    Wenn Sie dynamisches Unterteilen verwenden, müssen Sie die aktiven Segmente nicht zuerst löschen. Sub-Slices, die während eines Upgrades aktiv bleiben, schlagen jedoch fehl und wechseln in den Status FAILED.

  2. Aktualisieren Sie die Upgrade-Parameter für Ihren Knotenpool:

    gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --project=PROJECT_ID \
    --location=LOCATION \
    --max-surge-upgrade=0 \
    --max-unavailable-upgrade=16

    Achten Sie darauf, dass das Feld --max-surge-upgrade auf den Wert 0 gesetzt ist, damit GKE während des Upgrades nicht versucht, zusätzliche TPUs zuzuweisen. Wir empfehlen, das Feld --max-unavailable-upgrade=16 so festzulegen, dass ein vollständiger Unterblock mit 16 Knoten gleichzeitig aktualisiert wird.

  3. Knotenpool aktualisieren:

    gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=NODE_POOL_NAME \
    --cluster-version=CLUSTER_VERSION \
    --project=PROJECT_ID \
    --location=LOCATION

Hardwarewartung und ‑fehler

Wenn Sie eine vom Kunden initiierte Wartung auslösen oder ein Hardware-Failover auftritt, sind nur die Zielknoten und nicht der gesamte Knotenpool betroffen.

Bei dynamischem Super-Slicing müssen Sie Ihre aktiven dynamischen Slices löschen, bevor Sie die manuelle Wartung ausführen. Wenn Sie die dynamische Unterteilung verwenden, müssen Sie die aktiven Segmente nicht zuerst löschen. Wenn während der Aktivierung eines dynamischen Sub-Slice Wartungsarbeiten oder Hardwarefehler auftreten, geht das System so vor:

  1. Automatisches Anpassen der Form: GKE passt die Form des aktiven dynamischen Slice automatisch an, wenn die Wartung auf einem zugehörigen Host beginnt.
  2. Fehler bei benutzerdefinierter Slice-Ressource: Die benutzerdefinierte Slice-Ressource wechselt in den Status FAILED.
  3. Scheduler-Beobachtung: Der Scheduler beobachtet den Fehlerstatus der benutzerdefinierten Slice-Ressource.
  4. Reformation process (Prozess zur Wiederherstellung): Der Scheduler versucht automatisch, die Slice-Konfigurationen auf anderen verfügbaren fehlerfreien Knoten neu zu erstellen.

Slice Controller deaktivieren

Wenn Sie den Slice-Controller deaktivieren möchten, entfernen Sie ihn aus dem Cluster.

  1. Prüfen Sie, ob die benutzerdefinierten Slice-Ressourcen leer sind:

    kubectl get slice -A

  2. Aktualisieren Sie den Cluster, um den Slice-Controller zu deaktivieren:

    gcloud container clusters update ${CLUSTER_NAME} \
    --location=${REGION} \
    --no-enable-slice-controller

  3. Löschen Sie die benutzerdefinierte Slice-Ressource :

    kubectl delete crd slices.accelerator.gke.io

  4. Prüfen Sie, ob die benutzerdefinierte Ressource „Slice“ gelöscht wurde:

    kubectl get crd | grep slices.accelerator.gke.io

  5. Entfernen Sie die Labels, die vom Slice-Controller hinzugefügt wurden. Diese Labels müssen entfernt werden:

    • cloud.google.com/gke-tpu-slice
    • cloud.google.com/gke-tpu-topology
    1. Wenn Sie einen Knoten entfernen möchten, aktualisieren Sie den Knotennamen.
    export NODE_NAME="gke-tpu-bdac9600-3bdg"
kubectl label node $NODE_NAME cloud.google.com/gke-tpu-slice- cloud.google.com/gke-tpu-slice-topology-
    1. So entfernen Sie diese Labels von jedem Knoten in Ihrem Cluster:
    kubectl label nodes --all cloud.google.com/gke-tpu-slice- cloud.google.com/gke-tpu-slice-topology-
    1. Prüfen Sie die Knotenlabels und bestätigen Sie, dass sie leer sind:
    export NODE_NAME="gke-tpu-bdac9600-3bdg"
kubectl describe node $NODE_NAME | grep "cloud.google.com/gke-tpu-slice"

Nächste Schritte