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 diese Anleitung durcharbeiten, sollten Sie sich mit den Konzepten des dynamischen Aufteilens vertraut machen.

Warum dynamisches Slicing mit einem benutzerdefinierten Planer verwenden?

Verwenden Sie Ihren eigenen Planer, um benutzerdefinierte 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 benutzerdefinierte Slice-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. Erstellen Sie benutzerdefinierte Slice-Ressourcen basierend auf den Anforderungen Ihrer Arbeitslast. Wenden Sie die benutzerdefinierte Ressource „Slice“ auf Ihren Cluster an.
  4. Partitionsstatus und Slice-Zustand überwachen
  5. Löschen Sie den Ausschnitt, wenn Sie fertig sind.

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

Voraussetzungen

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

  • Verwenden Sie einen Standardcluster im Rapid Channel in einer der folgenden Versionen:
    • Verwenden Sie für die dynamische Super-Slicing-Konfiguration (Topologien gleich oder größer als 4x4x4) die Version 1.35.2-gke.1842000 oder höher.
    • Für die dynamische Konfiguration von Unterslices (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 „Gesamte Kapazität“ verwenden. Der Modus „Alle Kapazitäten“ ist eine Funktion, die von TPU Cluster Director aktiviert wird.
  • Für dynamisches Sub-Slicing müssen Ihre Knoten ausstehende Wartungsereignisse haben. Instanzen auf anstehende Wartungsereignisse überwachen Wenn für einen Ihrer Knoten ein ausstehendes Wartungsereignis mit einer Endzeit zwischen dem 18. September 2026 und dem 30. September 2026 geplant ist, müssen Sie das Hostwartungsereignis auf diesen Knoten manuell auslösen, bevor Sie Sub-Slicing 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, müssen Sie den Slice-Controller in Ihrem Cluster aktivieren.

  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 wandelt Ihre gesamte TPU-Kapazität in Knotenpools mit 16-Knoten-Gruppen von TPU-VMs oder Unterblöcken um. 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 Block von TPUs, der in Reservierungen im Modus „Gesamte Kapazität“ verfügbar gemacht wird. 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, in 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.

Gehen Sie in diesem Befehl so vor:

  • Setzen Sie das Feld accelerator-topology immer auf 4x4x4, damit es der Gesamtzahl der Chips in einem einzelnen Unterblock entspricht.
  • Setzen Sie das Feld accelerator-topology-mode immer auf provision_only, 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.
, um die Liste der Arbeitslastrichtlinien aufzurufen.

Knotenpool einem Block oder Unterblock zuweisen

Sie können bestimmte Unterblöcke oder Blöcke innerhalb Ihrer Reservierung im Modus „Gesamte Kapazität“ als Ziel festlegen.

  • 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 abzielen: Jeder Knotenpool wird einem bestimmten und verfügbaren Unterblock zugeordnet. Bei der Verwendung von Subblock-Targeting erstellt GKE den Knotenpool, wenn mindestens eine VM fehlerfrei ist. Durch die inkrementelle Bereitstellung wird sichergestellt, 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. Bestimmen 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 Arbeitslastrichtlinie.
    • 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. Wenn Sie den Namen des Blocks ermitteln möchten, listen Sie alle Reservierungsblöcke auf und kopieren Sie den Wert im Feld name:. Dieser Wert ist der Name des Blocks oder 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, aber ihre ICI-Links (Inter-Chip Interconnect) sind noch nicht aktiv. Daher können Sie Arbeitslasten nicht direkt in diesen Knotenpools ausführen.

Damit alle erforderlichen ICI-Links zum Erstellen des Slices gebildet werden und Arbeitslasten geplant 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. Vermeiden Sie es, von Kueue erstellte benutzerdefinierte Slice-Ressourcen manuell zu ändern.

Dynamischen Segment mit Super-Slicing 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.

Alle Slices, die größer als 4x4x4 sind, haben 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 Partitions-IDs und Knotenlabels für den 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, die Sie anvisieren 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 für die Bildung eines dynamischen Slice 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 Segmentierung verwendet werden. Dieser Status gilt nur für die 4x4x4-Topologie der obersten Ebene. Kleinere Topologien haben keinen beeinträchtigten Zustand.
    • UNHEALTHY: Die Partition funktioniert nicht richtig und kann nicht zum Erstellen eines Segments 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 Slice-Ressource variiert geringfügig, je nachdem, ob Sie ein dynamisches Super-Slice oder ein dynamisches 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 Slice. Der Name muss den metadata.name-Bedingungen 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 Sub-Slicing 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 dynamisches 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 Segmentierung 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 identifizieren, aus denen das Segment besteht.
      • Für dynamisches Unterteilen in Scheiben:Sie müssen 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 der Liste spec.partitionIds 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 sein.
        • Alle zugehörigen untergeordneten Blöcke müssen zur selben Reservierung gehören.
        • Alle zugehörigen Unterblöcke müssen sich in derselben Reservierung befinden.
        • Alle Knoten in den zugehörigen Knotenpools müssen den 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 ein 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 ein 2x2x2-Slice (dynamisches Sub-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, das Slice zu erstellen. Wenn eines der folgenden Probleme auftritt, schlägt die Erstellung des Slices 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 Slice-Ressource 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 dynamisches Sub-Slicing oder dynamisches Super-Slicing verwenden.

Statusbedingungen für dynamisches Unterteilen

  • SliceNotCreated: Der Controller führt Initialisierungs- und Ressourcenprüfungen durch.
    • Wenn die Voraussetzungen nicht erfüllt sind, ändert sich der Status zu SliceCreationFailed.
    • Wenn die Validierung erfolgreich ist, wechselt der Status zu ACTIVATING.
  • ACTIVATING: GKE bildet den Slice.
    • Bei Erfolg ändert sich der Status zu ACTIVE.
    • Wenn Unterblöcke eingeschränkt sind, der Slice aber nutzbar ist, wechselt 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 wurden (z. B. fehlen erforderliche Compute Engine-Ressourcen) oder die Preflight-Prüfungen fehlgeschlagen sind. Wenn die Segmentbildung in diesem Status automatisch wiederholt werden soll, konfigurieren Sie die slice.gke.io/retry-on-failure: "true"-Annotation.
  • ACTIVATING: Das Segment wird gerade zusammengesetzt.
  • 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 eingeschränkte Cubes, die durch ICI-Robustheit unterstützt werden. Arbeitslasten können ausgeführt werden, aber die Leistung ist möglicherweise beeinträchtigt. Das dynamische 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: Der Slice wird gerade abgebaut.
  • FAILED: Das Slice ist nicht mehr bereit, Arbeitslasten auszuführen. Dieser Status tritt auf, wenn die anfängliche Bildung fehlgeschlagen ist oder bei einem aktiven Slice ein schwerwiegender Software- oder Hardwarefehler aufgetreten ist.
  • INCOMPLETE: Es sind nicht genügend Cubes verfügbar, um die Super-Slice-Bildung zu starten.

Weitere Informationen zum Status der benutzerdefinierten Slice-Ressource 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 gezeigt.

  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 in Multislice-Knotenpools mit JobSet 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 ist JobSet v0.11.1 oder höher erforderlich.

  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 der einzelnen dynamischen Slices definiert.
    • Die Umgebungsvariable TPU_ACCELERATOR_TYPE wird in diesem Beispiel nicht explizit festgelegt, da JobSet die Slice-Zuweisung übernimmt. Der JAX-Code erkennt die verfügbaren TPU-Geräte im zugewiesenen Slice automatisch.

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 der Slice gelöscht wurde:

    kubectl get slices

Upgrade der Knotenpools durchführen

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

So konfigurieren Sie das Knotenpool-Upgrade und führen es 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 Sub-Slicing verwenden, müssen Sie die aktiven Slices 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. Führen Sie ein Upgrade des Knotenpools durch:

    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 betroffen, nicht der gesamte Knotenpool.

Für das dynamische Super-Slicing müssen Sie Ihre aktiven dynamischen Slices löschen, bevor Sie die manuelle Wartung ausführen. Wenn Sie dynamische Untersegmente 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 der benutzerdefinierten Slice-Ressource: Die benutzerdefinierte Slice-Ressource wechselt in den Status FAILED.
  3. Scheduler-Beobachtung: Der Scheduler beobachtet den Fehlerstatus der benutzerdefinierten Slice-Ressource.
  4. Reformationsprozess: 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 vom Slice-Controller hinzugefügten Labels. Diese Labels müssen entfernt werden:

    • cloud.google.com/gke-tpu-slice
    • cloud.google.com/gke-tpu-topology
    1. Wenn Sie die Datei von einem bestimmten 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