Dynamische Slices mit Kueue und TAS planen

In diesem Dokument wird erläutert, wie Sie TPU-Knotenpools bereitstellen und dynamische Slices in Google Kubernetes Engine (GKE) mithilfe von Kueue und Topology-Aware Scheduling (TAS) planen.

Sie können das dynamische Slicing auch verwenden, indem Sie direkt mit benutzerdefinierten Slice-Ressourcen interagieren. Weitere Informationen finden Sie unter Dynamisches Slicing mit einem benutzerdefinierten Planer verwenden.

Bevor Sie diese Anleitung befolgen, sollten Sie sich mit den Konzepten des dynamischen Slicings vertraut machen.

Voraussetzungen

Für die Verwendung von dynamischem Slicing in GKE müssen die folgenden Anforderungen erfüllt sein:

  • 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.
    • Verwenden Sie für die dynamische Sub-Slicing-Konfiguration (Topologien kleiner als 4x4x4) die 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 ausstehende 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. Ältere gcloud CLI-Versionen unterstützen möglicherweise nicht die Ausführung der Befehle in diesem Dokument.

Dynamisches Slicing in GKE mit Kueue verwenden

In diesem Abschnitt wird der Workflow für die Verwendung von dynamischem Slicing in GKE beschrieben.

  1. Topologie und Systemstatus von Reservierungen im Modus „Gesamte Kapazität“ ansehen
  2. Aktivieren Sie den Slice-Controller in Ihrem Cluster.
  3. Installieren Sie Kueue, JobSet und LWS.
  4. TPU-Knotenpools erstellen
  5. Kueue so konfigurieren, dass eine benutzerdefinierte Slice-Ressource erstellt wird
  6. Arbeitslasten mit dynamischem Slicing mit Kueue ausführen
  7. Führen Sie eine Bereinigung durch.

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 die 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

Kueue, JobSet und LWS installieren

Wenn Sie Kueue, JobSet und LWS bereits installiert haben, können Sie diesen Abschnitt überspringen.

Kueue installieren

Folgen Sie der Anleitung in der Kueue-Dokumentation oder führen Sie den folgenden Befehl aus:

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

Ersetzen Sie KUEUE_VERSION durch die erforderliche Kueue-Version gemäß Ihren Topologieanforderungen. Verwenden Sie für dynamisches Sub-Slicing Kueue v0.18.2 oder höher. Verwenden Sie für dynamisches Super-Slicing Kueue v0.16.6 oder höher.

JobSet installieren

Folgen Sie der Anleitung in der JobSet-Dokumentation oder führen Sie den folgenden Befehl aus:

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

Ersetzen Sie JOBSET_VERSION durch die erforderliche JobSet-Version, die Ihren Topologieanforderungen entspricht. Verwenden Sie für dynamisches Sub-Slicing JobSet v0.12.0 oder höher. Verwenden Sie für dynamisches Super-Slicing JobSet v0.11.1 oder höher.

LWS installieren

LeaderWorkerSet (LWS) ist nur für dynamisches Sub-Slicing erforderlich.

Folgen Sie der Anleitung in der LWS-Dokumentation oder führen Sie den folgenden Befehl aus:

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

Ersetzen Sie LWS_VERSION durch die erforderliche LWS-Version. Verwenden Sie LWS v0.8.0 oder höher.

Knotenpools mit inkrementeller Bereitstellung erstellen

In diesem Abschnitt wird beschrieben, wie Sie die TPU-Knotenpools mit inkrementeller Bereitstellung erstellen. Die GKE wandelt Ihre gesamte TPU-Kapazität in Knotenpools um, die aus 16-Knoten-Gruppen von Ironwood-VMs (TPU7x) oder Unterblöcken bestehen. GKE stellt diese Knotenpools auch dann bereit, wenn nicht alle fehlerfreien VMs gefunden werden können. Dazu werden Knoten auf fehlerfreien Teilen der Hostmaschine platziert und fehlerhafte Maschinen schrittweise bereitgestellt, während sie repariert werden.

Sie können Ihren Knotenpool so ausrichten, dass er zu einer der folgenden Optionen gehört:

  • Ein bestimmter Block von TPUs, der in Reservierungen im Modus „Gesamte Kapazität“ verfügbar gemacht wird. Mit der Blockausrichtung kann GKE den Knotenpool in einem beliebigen verfügbaren Unterblock innerhalb des angegebenen Blocks erstellen.
  • Einen bestimmten Unterblock oder eine bestimmte Gruppe von 16 Ironwood-VMs (TPU7x) 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 Folgendes aus:

  • Setzen Sie das Feld accelerator-topology immer auf 4x4x4, um die Gesamtzahl der Chips in einem einzelnen Unterblock zu erreichen.
  • 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, stellt der Knotenpool TPU-Knoten bereit, ohne ICI- oder OCS-Links zu bilden.

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. Wenn Sie das Targeting auf Unterblöcke verwenden, erstellt GKE den Knotenpool, wenn mindestens eine VM fehlerfrei ist. Die inkrementelle Bereitstellung trägt dazu bei, dass alle Knoten im angegebenen Subblock platziert werden.

Blockieren

  1. Führen Sie die folgenden Schritte im Dokument Topologie und Systemzustand von Reservierungen im All Capacity Mode ansehen aus, um den Namen des Blocks in einer Reservierung und die Anzahl der verfügbaren Unterblöcke im Block abzurufen:

    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 ist die Anzahl der verfügbaren Unterblöcke. Der Wert reservationSubBlockCount: 4 gibt beispielsweise an, dass der Block vier Unterblöcke hat und Sie vier separate Knotenpools erstellen müssen.

  2. Legen Sie den Reservierungspfad fest:

    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 identifizierten 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 aller Reservierungen im All-Capacity-Modus 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. Legen Sie den Reservierungspfad fest:

    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. Erstellen Sie den Knotenpool:

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

Wenn Sie alle erforderlichen ICI-Links aktivieren möchten, um den Slice zu bilden und das Planen von Arbeitslasten zu ermöglichen, 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 Slice mit Kueue und TAS erstellen

In diesem Abschnitt planen Sie GKE-Arbeitslasten mit Kueue und TAS.

Kueue-Slice-Controller installieren

  1. Speichern Sie das folgende Manifest als slice-controller.yaml, um den Kueue-Slice-Controller zu installieren:

    # 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: Namespace
metadata:
  labels:
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/name: slice-controller
    control-plane: controller-manager
  name: slice-controller-system
---
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/name: slice-controller
    control-plane: controller-manager
  name: slice-controller-controller-manager
  namespace: slice-controller-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  labels:
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/name: slice-controller
    control-plane: controller-manager
  name: slice-controller-leader-election-role
  namespace: slice-controller-system
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
  - delete
- apiGroups:
  - coordination.k8s.io
  resources:
  - leases
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
  - delete
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - patch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  labels:
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/name: slice-controller
    control-plane: controller-manager
  name: slice-controller-webhook-secrets-role
  namespace: slice-controller-system
rules:
- apiGroups:
  - ""
  resources:
  - secrets
  verbs:
  - get
  - list
  - watch
  - update
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    control-plane: controller-manager
  name: slice-controller-manager-role
rules:
- apiGroups:
  - ""
  resources:
  - nodes
  - pods
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - accelerator.gke.io
  resources:
  - slices
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - accelerator.gke.io
  resources:
  - slices/finalizers
  verbs:
  - update
- apiGroups:
  - accelerator.gke.io
  resources:
  - slices/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - admissionregistration.k8s.io
  resources:
  - mutatingwebhookconfigurations
  verbs:
  - get
  - list
  - update
  - watch
- apiGroups:
  - batch
  resources:
  - jobs
  verbs:
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - events.k8s.io
  resources:
  - events
  verbs:
  - create
  - patch
  - update
  - watch
- apiGroups:
  - jobset.x-k8s.io
  resources:
  - jobsets
  verbs:
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - kueue.x-k8s.io
  resources:
  - admissionchecks
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - kueue.x-k8s.io
  resources:
  - admissionchecks/status
  - workloads/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - kueue.x-k8s.io
  resources:
  - workloads
  verbs:
  - create
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - leaderworkerset.x-k8s.io
  resources:
  - leaderworkersets
  verbs:
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ray.io
  resources:
  - rayclusters
  - rayjobs
  verbs:
  - get
  - list
  - patch
  - update
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    control-plane: controller-manager
  name: slice-controller-metrics-auth-role
rules:
- apiGroups:
  - authentication.k8s.io
  resources:
  - tokenreviews
  verbs:
  - create
- apiGroups:
  - authorization.k8s.io
  resources:
  - subjectaccessreviews
  verbs:
  - create
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    control-plane: controller-manager
  name: slice-controller-metrics-reader
rules:
- nonResourceURLs:
  - /metrics
  verbs:
  - get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  labels:
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/name: slice-controller
    control-plane: controller-manager
  name: slice-controller-leader-election-rolebinding
  namespace: slice-controller-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: slice-controller-leader-election-role
subjects:
- kind: ServiceAccount
  name: slice-controller-controller-manager
  namespace: slice-controller-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  labels:
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/name: slice-controller
    control-plane: controller-manager
  name: slice-controller-webhook-secrets-rolebinding
  namespace: slice-controller-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: slice-controller-webhook-secrets-role
subjects:
- kind: ServiceAccount
  name: slice-controller-controller-manager
  namespace: slice-controller-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/name: slice-controller
    control-plane: controller-manager
  name: slice-controller-manager-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: slice-controller-manager-role
subjects:
- kind: ServiceAccount
  name: slice-controller-controller-manager
  namespace: slice-controller-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    control-plane: controller-manager
  name: slice-controller-metrics-auth-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: slice-controller-metrics-auth-role
subjects:
- kind: ServiceAccount
  name: slice-controller-controller-manager
  namespace: slice-controller-system
---
apiVersion: v1
kind: Secret
metadata:
  labels:
    control-plane: controller-manager
  name: slice-controller-webhook-server-cert
  namespace: slice-controller-system
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/name: slice-controller
    control-plane: controller-manager
  name: slice-controller-controller-manager-metrics-service
  namespace: slice-controller-system
spec:
  ports:
  - name: https
    port: 8443
    protocol: TCP
    targetPort: 8443
  selector:
    app.kubernetes.io/name: slice-controller
    control-plane: controller-manager
---
apiVersion: v1
kind: Service
metadata:
  labels:
    control-plane: controller-manager
  name: slice-controller-webhook-service
  namespace: slice-controller-system
spec:
  ports:
  - port: 443
    protocol: TCP
    targetPort: 9443
  selector:
    control-plane: controller-manager
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/name: slice-controller
    control-plane: controller-manager
  name: slice-controller-controller-manager
  namespace: slice-controller-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: slice-controller
      control-plane: controller-manager
  template:
    metadata:
      annotations:
        kubectl.kubernetes.io/default-container: manager
      labels:
        app.kubernetes.io/name: slice-controller
        control-plane: controller-manager
    spec:
      containers:
      - args:
        - --metrics-bind-address=:8443
        - --leader-elect
        - --health-probe-bind-address=:8081
        - --zap-log-level=3
        - --feature-gates=UseRetryMechanismForSliceCreation=true
        - --activation-timeout=60m
        - --kube-api-qps=100
        - --kube-api-burst=200
        - --default-slice-health-node-affinity=HEALTHY_AND_DEGRADED
        - --reuse-slices=true
        - --add-preferred-node-affinity=true
        command:
        - /manager
        image: tpuongke/kueue-slice-controller:v0.10
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8081
          initialDelaySeconds: 15
          periodSeconds: 20
        name: manager
        ports:
        - containerPort: 9443
          name: webhook-server
          protocol: TCP
        readinessProbe:
          httpGet:
            path: /readyz
            port: 8081
          initialDelaySeconds: 5
          periodSeconds: 10
        resources:
          limits:
            cpu: 12
            memory: 32Gi
          requests:
            cpu: 8
            memory: 16Gi
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
        volumeMounts:
        - mountPath: /tmp/k8s-webhook-server/serving-certs
          name: cert
          readOnly: true
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      serviceAccountName: slice-controller-controller-manager
      terminationGracePeriodSeconds: 10
      volumes:
      - name: cert
        secret:
          defaultMode: 420
          secretName: slice-controller-webhook-server-cert
---
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  labels:
    control-plane: controller-manager
  name: slice-controller-mutating-webhook-configuration
webhooks:
- admissionReviewVersions:
  - v1
  clientConfig:
    service:
      name: slice-controller-webhook-service
      namespace: slice-controller-system
      path: /mutate-batch-v1-job
  failurePolicy: Fail
  name: mjob.kb.io
  rules:
  - apiGroups:
    - batch
    apiVersions:
    - v1
    operations:
    - CREATE
    resources:
    - jobs
  sideEffects: None
- admissionReviewVersions:
  - v1
  clientConfig:
    service:
      name: slice-controller-webhook-service
      namespace: slice-controller-system
      path: /mutate-jobset-x-k8s-io-v1alpha2-jobset
  failurePolicy: Fail
  name: mjobset.kb.io
  rules:
  - apiGroups:
    - jobset.x-k8s.io
    apiVersions:
    - v1alpha2
    operations:
    - CREATE
    resources:
    - jobsets
  sideEffects: None
- admissionReviewVersions:
  - v1
  clientConfig:
    service:
      name: slice-controller-webhook-service
      namespace: slice-controller-system
      path: /mutate-leaderworkerset-x-k8s-io-v1-leaderworkerset
  failurePolicy: Fail
  name: mleaderworkerset.kb.io
  rules:
  - apiGroups:
    - leaderworkerset.x-k8s.io
    apiVersions:
    - v1
    operations:
    - CREATE
    resources:
    - leaderworkersets
  sideEffects: None
- admissionReviewVersions:
  - v1
  clientConfig:
    service:
      name: slice-controller-webhook-service
      namespace: slice-controller-system
      path: /mutate-ray-io-v1-raycluster
  failurePolicy: Fail
  name: mraycluster.kb.io
  rules:
  - apiGroups:
    - ray.io
    apiVersions:
    - v1
    operations:
    - CREATE
    resources:
    - rayclusters
  sideEffects: None
- admissionReviewVersions:
  - v1
  clientConfig:
    service:
      name: slice-controller-webhook-service
      namespace: slice-controller-system
      path: /mutate-ray-io-v1-rayjob
  failurePolicy: Fail
  name: mrayjob.kb.io
  rules:
  - apiGroups:
    - ray.io
    apiVersions:
    - v1
    operations:
    - CREATE
    resources:
    - rayjobs
  sideEffects: None

  2. Wenden Sie das slice-controller.yaml-Manifest an:

    kubectl apply -f slice-controller.yaml

  3. Speichern Sie das folgende Manifest als dynamic-slice-topology.yaml, um Kueue für dynamisches Slicing zu konfigurieren:

    # 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: kueue.x-k8s.io/v1beta1
kind: Topology
metadata:
  name: superslice-topology
spec:
  levels:
  # Label to identify the physical block a sub-block belongs to.
  # Only sub-blocks from the same block can form a slice.
  - nodeLabel: cloud.google.com/gce-topology-block
  # Label to identify individual TPU sub-blocks (4x4x4 topology).
  - nodeLabel: cloud.google.com/gke-tpu-partition-4x4x4-id
  # Standard Kubernetes label for individual nodes.
  # Required to assign Pods to specific VMs.
  - nodeLabel: kubernetes.io/hostname
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ResourceFlavor
metadata:
  name: superslice-rf
spec:
  nodeLabels:
    cloud.google.com/gke-tpu-accelerator: tpu7x
  topologyName: superslice-topology
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: AdmissionCheck
metadata:
  name: superslice-ac
spec:
  controllerName: accelerator.gke.io/slice
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: ClusterQueue
metadata:
  name: cq
spec:
  namespaceSelector: {}
  admissionChecks:
  - superslice-ac
  resourceGroups:
  - coveredResources:
    - google.com/tpu
    flavors:
    - name: superslice-rf
      resources:
      - name: google.com/tpu
        nominalQuota: "999999"  # modeling unlimited quota
---
apiVersion: kueue.x-k8s.io/v1beta1
kind: LocalQueue
metadata:
  name: lq
  namespace: default
spec:
  clusterQueue: cq

  4. Wenden Sie das dynamic-slice-topology.yaml-Manifest an:

    kubectl apply -f dynamic-slice-topology.yaml

    In diesem Manifest konfigurieren Sie Kueue für das dynamische Slicing, indem Sie die folgenden Ressourcen definieren:

    • Ironwood (TPU7x) dynamische Slice-Topologie (superslice-topology): Die Topologie definiert die Ebenen, die Kueue bei der Planung von Arbeitslasten mit dynamischem Slicing berücksichtigt. Diese Ebenen sind:
      • cloud.google.com/gce-topology-block-Label: Dieses Level ist erforderlich, um zu verstehen, welche Unterblöcke zu welchen Blöcken gehören, da nur Unterblöcke aus demselben Block einen Slice bilden können.
      • cloud.google.com/gke-tpu-partition-4x4x4-id-Label: Diese Ebene stellt einzelne Ironwood-Unterblöcke (TPU7x) dar (4x4x4-Topologie).
      • kubernetes.io/hostname-Label: Diese Ebene ist erforderlich, um Pods bestimmten VMs zuzuweisen und ihre Labels und Markierungen zu beobachten.
    • Ironwood (TPU7x) SuperSlice ResourceFlavor (superslice-rf): Die Ressourcenvariante für Ironwood (TPU7x)-Unterblöcke enthält das Label cloud.google.com/gke-tpu-accelerator: tpu7x, um Knoten mit Ironwood (TPU7x)-Maschinen abzugleichen.
    • SuperSlice AdmissionCheck (superslice-ac): Diese Zulassungsprüfung weist Kueue an, eine Arbeitslast erst dann zu planen, wenn der GKE-Slice-Controller bestätigt, dass der Slice aktiv ist. Die Zulassungsprüfung wird zuerst definiert und dann dem ClusterQueue hinzugefügt, der Arbeitslasten für dynamisches Slicing verarbeitet.
    • ClusterQueue (cq) und LocalQueue (lq): Diese Felder verwalten google.com/tpu-Ressourcen. Die ClusterQueue cq enthält die Zulassungsprüfung superslice-ac. Das Feld nominalQuota für google.com/tpu kann auf zwei Arten konfiguriert werden:
      • Spezifisches Kontingent: Legen Sie das Feld nominalQuota so fest, dass es der vorhandenen Kapazität für die faire Freigabe und die Kontingentverwaltung entspricht.
      • Unbegrenztes Kontingent: Setzen Sie das Feld nominalQuota auf einen sehr hohen Wert wie "999999", um ein unbegrenztes Kontingent zu modellieren. Damit der Fokus auf TAS und dynamischem Slicing liegt, wird bei dieser Konfiguration die Kontingentverwaltungsfunktion von Kueue umgangen.

Auswahl des Partitionszustands definieren

Zusätzlich zum Standardzustand und zur Standardbereitschaft von Knoten stellt GKE den spezifischen Zustand jeder Partitionsform über das Label cloud.google.com/gke-tpu-partition-[shape]-state bereit (wobei [shape] der Partitions-ID-Form entspricht, z. B. 2x2x1, 2x2x2, 2x2x4, 2x4x4 oder 4x4x4). Mit diesem Label kann GKE Faktoren berücksichtigen, die die Slice-Bildung beeinflussen, z. B. den Zustand von TPU-Links. Für die dynamische Sub-Slicing-Konfiguration (Topologien kleiner als 4x4x4) ist die GKE-Version 1.36.0-gke.3712000 oder höher erforderlich.

Sie können den Wert des Labels für den Partitionsstatus so definieren:

  • HEALTHY: Die Partition ist fehlerfrei und voll funktionsfähig.
  • DEGRADED: Die Infrastruktur der Partition ist in einem beeinträchtigten Zustand, z. B. aufgrund einer Beeinträchtigung der OCS-Verbindung. Die Partition kann weiterhin ein Slice bilden, aber die Gesamtleistung ist möglicherweise geringer als bei fehlerfreien Partitionen. Dieser Status gilt nur für die 4x4x4-Topologie der obersten Ebene. Kleinere Topologien haben keinen beeinträchtigten Zustand.
  • UNHEALTHY: Die Partition ist fehlerhaft und kann kein Slice bilden.
  • UNSET: Der Status ist aufgrund einer fehlgeschlagenen Initialisierung des GKE-Slice-Controllers nicht definiert.
  • INCOMPLETE: Nicht alle Knoten innerhalb der Partition sind bereitgestellt.

Der Webhook des Kueue-Slice-Controllers prüft, ob eine Arbeitslast eine bestimmte Anforderung an den Zustand der Partition enthält. Wenn keine Präferenz angegeben ist, fügt der Webhook eine Standardknotenaffinität ein.

Das Verhalten ist wie folgt:

  • Wenn ein nodeSelector oder nodeAffinity vorhanden ist, das auf das Label cloud.google.com/gke-tpu-partition-[shape]-state abzielt, bleibt es unverändert.

  • Wenn keine solche Labelkonfiguration vorhanden ist, fügt der Webhook die folgende Standardknotenaffinität ein, um sicherzustellen, dass nur verfügbare Partitionen verwendet werden:

    nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
    - matchExpressions:
      - key: cloud.google.com/gke-tpu-partition-4x4x4-state
        operator: In
        values:
        - "HEALTHY"
        - "DEGRADED"

Im folgenden Abschnitt finden Sie Beispiele, in denen das Label cloud.google.com/gke-tpu-partition-4x4x4-state so konfiguriert ist, dass die verschiedenen Integritätskonfigurationen für Unterblöcke angegeben werden.

Testarbeitslasten für dynamisches Slicing mit Kueue ausführen

In diesem Abschnitt wird beschrieben, wie Sie Arbeitslasten mit Kueue und TAS auf dynamischem Slicing bereitstellen. Es enthält Beispiele, die zeigen, wie Sie eine Arbeitslast mit dynamischem Slice und eine Arbeitslast mit mehreren Slices erstellen. Die Arbeitslasten werden als JobSets gesendet.

Beispiel 1: Einzelne Arbeitslast verwendet ein einzelnes dynamisches Slice

Im folgenden Beispiel wird beschrieben, wie Sie eine Arbeitslast mit einem Slice mit einer 4x12x16-Topologie erstellen, die aus 12 Unterblöcken besteht. Die Anzahl der Pods wurde so berechnet: (4 * 12 * 16) / 4 Chips pro Knoten = 192 Pods.

  1. Speichern Sie das folgende Manifest als big-super-slice.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: big-super-slice
  labels:
    kueue.x-k8s.io/queue-name: lq
spec:
  replicatedJobs:
    - name: job-jax
      replicas: 1
      template:
        spec:
          parallelism: 192  # pods per slice calculation: 4*12*16 / 4 = 192
          completions: 192
          backoffLimit: 10
          template:
            metadata:
              annotations:
                cloud.google.com/gke-tpu-slice-topology: 4x12x16
            spec:
              tolerations:
                - key: "google.com/tpu"
                  operator: "Equal"
                  value: "present"
                  effect: "NoSchedule"
              nodeSelector:
                cloud.google.com/gke-tpu-accelerator: tpu7x
              containers:
                - name: jax
                  image: python:latest
                  command:
                    - bash
                    - -c
                    - |
                      printenv
                      pip install "jax[tpu]" -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
                      python -c 'import jax; print("Global device count:", jax.device_count(), "Local device count:", jax.local_device_count())'
                  resources:
                    limits:
                      google.com/tpu: 4
              restartPolicy: Never

    In diesem Manifest teilen die folgenden Annotationen Kueue die Slice-Eigenschaften und die Topologie mit, um Folgendes zu konfigurieren:

    • cloud.google.com/gke-tpu-slice-topology: Gibt "4x12x16" als Topologie für das dynamische Slice an. Für die Beschleunigertopologie tpu7x gelten die folgenden Regeln:
      • Für dynamisches Sub-Slicing: Sie können 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. Bei der dynamischen Super-Slicing-Konfiguration muss jede Dimension der angeforderten Topologie ein Vielfaches von vier sein, z. B. 4A x 4B x 4C.
      • Die Topologie muss ein dreidimensionaler String im Format AxBxC sein, z. B. 4x8x8.
      • Die Dimensionen müssen in nicht absteigender Reihenfolge sortiert sein: A <= B <= C. Beispiel: 4x8x4 ist ungültig und sollte 4x4x8 sein.
      • Das Produkt der Dimensionen (ABC) darf 9.216 nicht überschreiten.
      • Die größten unterstützten Slice-Topologien können bis zu 32 Unterblöcke enthalten. Beispielsweise liegen 8x16x16 mit 32 Unterblöcken, 8x12x20 mit 30 Unterblöcken oder 12x12x12 mit 27 Unterblöcken innerhalb der zulässigen Limits.
    • cloud.google.com/gke-tpu-accelerator: tpu7x: Plant Pods auf VMs, auf denen Ironwood (TPU7x) ausgeführt wird.
    • kueue.x-k8s.io/queue-name: weist das JobSet einer lokalen Kueue-Warteschlange zu.
    • Der Webhook fügt die Standardknotenaffinität ein, um sicherzustellen, dass HEALTHY- und DEGRADED-Knoten verwendet werden.

  2. Wenden Sie das big-super-slice.yaml-Manifest an:

    kubectl apply -f big-super-slice.yaml

    Nachdem Sie das Manifest angewendet haben, erstellt Kueue eine JobSet mit dem Namen big-super-slice. Kueue versucht dann, einen einzelnen dynamischen Slice mit einer 4x12x16-Topologie zu erstellen. Nachdem der Slice aktiv ist, lässt Kueue die Arbeitslast zu und die 192 Pods werden auf den Knoten geplant, um den dynamischen Slice zu bilden, auf dem Ihre Arbeitslasten ausgeführt werden.

Beispiel 2: Arbeitslast mit mehr als einem Replikat

Im folgenden Beispiel wird gezeigt, wie Sie eine Arbeitslast erstellen, die zwei dynamische Slices verwendet, die jeweils aus vier Unterblöcken bestehen, die nur auf HEALTHY-Knoten abzielen.

  1. Speichern Sie das folgende Manifest als two-super-slices.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: two-super-slices
  labels:
    kueue.x-k8s.io/queue-name: lq
spec:
  replicatedJobs:
    - name: job-jax
      replicas: 2
      template:
        spec:
          parallelism: 64  # Pods per slice calculation: (4*8*8) / 4 = 64
          completions: 64
          backoffLimit: 10
          template:
            metadata:
              annotations:
                cloud.google.com/gke-tpu-slice-topology: 4x8x8
            spec:
              tolerations:
                - key: "google.com/tpu"
                  operator: "Equal"
                  value: "present"
                  effect: "NoSchedule"
              nodeSelector:
                cloud.google.com/gke-tpu-accelerator: tpu7x
                cloud.google.com/gke-tpu-partition-4x4x4-state: "HEALTHY"
              containers:
                - name: jax
                  image: python:latest
                  command:
                    - bash
                    - -c
                    - |
                      printenv
                      pip install "jax[tpu]" -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
                      python -c 'import jax; print("Global device count:", jax.device_count(), "Local device count:", jax.local_device_count())'
                  resources:
                    limits:
                      google.com/tpu: 4
              restartPolicy: Never

  2. Wenden Sie das two-super-slices.yaml-Manifest an:

    kubectl apply -f two-super-slices.yaml

In diesem Manifest legen Sie im Abschnitt replicatedJobs das Feld replicas auf 2 fest. Nachdem Sie das Manifest angewendet haben, versucht Kueue, zwei separate Slices mit einer 4x8x8-Topologie zu bilden. Kueue erstellt für jedes in jobset.spec.replicatedJobs[].replicas definierte Replikat ein dynamisches Slice. Wenn n Replikate angegeben sind, erstellt Kueue n dynamische Slices für die Arbeitslast und wartet, bis alle Slices aktiv sind, bevor die Arbeitslast zugelassen wird.

Arbeitslastplanung mit Slice-Wiederverwendung optimieren

Standardmäßig weist Kueue den Slice-Controller an, für jede Arbeitslastausführung ein neues TPU-Slice bereitzustellen und es nach Abschluss der Arbeitslast zu löschen. Dieses Verhalten kann zu Abwanderung und Mehraufwand für die zugrunde liegende Infrastruktur führen.

Mit der Slice-Wiederverwendung können neue Arbeitslasten vorhandene, inaktive TPU-Slices mit identischer Topologie und identischen Hardwarelimits wiederverwenden. Wenn Sie die Slice-Wiederverwendung aktivieren, markiert Kueue das Slice am Ende eines Jobs als inaktiv, anstatt es zu löschen. Ein neuer Job, der dieselbe Partition anfordert, beansprucht und verwendet den Slice sofort wieder. Dadurch wird die Verzögerung bei der Hardwarebereitstellung umgangen.

Slice-Wiederverwendung aktivieren

Wenn Sie die Slice-Wiederverwendung vollständig optimieren möchten, müssen Sie sowohl den Slice-Controller als auch Kueue so konfigurieren, dass sie zusammenarbeiten.

  1. Slice-Controller konfigurieren: Aktualisieren Sie die Bereitstellungsargumente des Kueue-Slice-Controllers, um das Flag --reuse-slices=true einzufügen. Damit Arbeitslasten optimal auf vorhandenen Slices geplant werden, fügen Sie auch das Flag --add-preferred-node-affinity=true hinzu.

  2. Kueue konfigurieren (empfohlen): Damit Kueue die bevorzugten Vorschläge für die Knotenaffinität des Controllers verwenden kann, müssen Sie das Feature Gate TASRespectNodeAffinityPreferred in Ihrer Kueue-Konfiguration aktivieren.

    Bearbeiten Sie beispielsweise die ConfigMap kueue-manager-config, um das Feature Gate hinzuzufügen:

    apiVersion: v1
kind: ConfigMap
metadata:
  name: kueue-manager-config
  namespace: kueue-system
data:
  controller_manager_config.yaml: |
    apiVersion: config.kueue.x-k8s.io/v1beta1
    kind: Configuration
    featureGates:
      TASRespectNodeAffinityPreferred: true
    # ...

    Starten Sie nach dem Ändern der ConfigMap das Deployment kueue-controller-manager neu, um die Änderung zu erzwingen:

    kubectl rollout restart deploy kueue-controller-manager -n kueue-system

Löschen von Slices pro Arbeitslast erzwingen

Führen Sie die folgenden Schritte aus, um eine bestimmte Arbeitslast dazu zu bringen, ihre Slices zu bereinigen und die Wiederverwendung von Slices zu verhindern:

  1. Wenden Sie das folgende Label auf Ihre Job- oder JobSet-Definition an:

    kueue.gke.io/tpu-enforce-slice-deletion: "true"

    Nachdem Sie dieses Label angewendet haben, kann die Arbeitslast weiterhin auf einem vorhandenen inaktiven Slice geplant werden. Nach Abschluss der Arbeitslast wird der Slice jedoch endgültig gelöscht und nicht an den wiederverwendbaren Pool zurückgegeben.

  2. Konfigurieren Sie Kueue so, dass dieses Label vom Framework-Job an das Kueue-Arbeitslastobjekt weitergegeben wird. Fügen Sie dazu das Label der Liste labelKeysToCopy in Ihrer Kueue-Konfiguration hinzu:

    labelKeysToCopy:
- "kueue.gke.io/tpu-enforce-slice-deletion"

Slice überwachen

Sie können den Status des Slice einsehen und die Slice-Messwerte mit GKE-Systemmesswerten überwachen.

Status des Slice überwachen

Wenn ein Slice erstellt oder aktiv von einer Arbeitslast verwendet wird, fügt der Slice-Controller Labels hinzu, um die Arbeitslast zu identifizieren, die ihn verwendet. Da Slice-Namen dynamisch generiert werden (und vom Namen der Arbeitslast entkoppelt sind, wenn die Wiederverwendung aktiviert ist), sollten Sie diese Labels verwenden, um das Slice zu finden, das Ihrer Arbeitslast zugewiesen ist.

  1. Führen Sie den folgenden Befehl aus, um die Slices zu finden, die einer Arbeitslast zugewiesen sind:

    kubectl get slice -l kueue.gke.io/tpu-slice-used-by-namespace=NAMESPACE,kueue.gke.io/tpu-slice-used-by-workload=WORKLOAD_NAME

    Ersetzen Sie Folgendes:

    • NAMESPACE: Namespace Ihrer Arbeitslast.
    • WORKLOAD_NAME: der Name der Kueue-Arbeitslast, der in der Regel mit dem Namen Ihres Jobs oder JobSets übereinstimmt.

  2. Kopieren Sie den Slice-Namen aus der Ausgabe des vorherigen Befehls.

  3. Verwenden Sie den Slice-Namen, um den detaillierten Status Ihres dynamischen Slice zu prüfen:

    kubectl describe slice SLICE_NAME

    Ersetzen Sie SLICE_NAME durch den Namen Ihres Slices.

Die Ausgabe sieht etwa so aus:

Name:         s-4x4x4-74d3fb0b
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  accelerator.gke.io/v1beta1
Kind:         Slice
Metadata:
  Creation Timestamp:  2026-02-12T23:44:28Z
  Finalizers:
    accelerator.gke.io/slice-finalizer
  Generation:        1
  Resource Version:  1770939905695871008
  UID:               6dbbfe14-4486-4462-864d-e078d0ca8b5b
Spec:
  Partition Ids:
    5eae6a4f59d59cf30a9bf49de618eb2b
  Topology:  4x4x4
  Type:      tpu7x
Status:
  Conditions:
    Last Transition Time:  2026-02-12T23:45:05Z
    Message:
    Reason:                ACTIVE
    Status:                True
    Type:                  Ready
    Last Transition Time:  2026-02-12T23:45:05Z
    Message:               NodeLabelingCompleted
    Reason:                NodeLabelIsAdded
    Status:                True
    Type:                  NodeLabeled
Events:                    <none>

Messwerte des Slice überwachen

Sie können die folgenden GKE-Systemmesswerte überwachen, die den Zustand eines Slice anzeigen:

  • kubernetes.io/accelerator/slice/state
  • kubernetes.io/accelerator/partition/state
  • kubernetes.io/accelerator/slice/deformation_durations
  • kubernetes.io/accelerator/slice/formation_durations

Weitere Informationen zu den Messwerten finden Sie unter GKE-Systemmesswerte.

Kueue-Slice-Controller-Messwerte

Sie können auch die folgenden Prometheus-Messwerte überwachen, die vom Kueue Slice Controller bereitgestellt werden, um den Lebenszyklus, die Wiederverwendung und die Zulassungsprüfungen von Slices zu beobachten:

Messwerte zum Lebenszyklus von Slices

Messwerte zum Slice-Lebenszyklus erfassen das Erstellen und Löschen von Slices:

  • tpu_ac_slice_create_time: Histogramm, das zeigt, wie lange die Erstellung des Slices gedauert hat.
  • tpu_ac_slices_created: Zähler, der erstellte Slices erfasst (enthält ein is_reusable-Label).
  • tpu_ac_slices_status: Gauge, die die aktuelle Anzahl der Slices nach Status erfasst, einschließlich der Labels is_reusable und in_use.
  • tpu_ac_slice_delete_time: Histogramm, das zeigt, wie lange das Löschen von Slices gedauert hat.
  • tpu_ac_slices_deleted: Zähler, der gelöschte Slices erfasst.
  • tpu_ac_slices_gc: Durch das Zähler-Tracking wurden Slices automatisch bereinigt.

Messwerte zur Wiederverwendung von Slices

Messwerte zur Slice-Wiederverwendung erfassen die erfolgreiche Wiederverwendung und Konflikte von TPU-Slices:

  • tpu_ac_slices_reused: Zähler, der erfolgreich wiederverwendete Slices erfasst.
  • tpu_ac_slices_conflict: Zähler, der die Slices erfasst, die aufgrund von Topologie- oder Formabweichungen gelöscht wurden.

Arbeitslast- und Zulassungsmesswerte

Arbeitslast- und Zulassungsmesswerte erfassen die Dauer und die Ergebnisse von Zulassungsprüfungen:

  • tpu_ac_admission_time: Histogramm, das die Dauer des Zulassungsprüfungsprozesses misst. Hinweis: Hier wird die Dauer der Zulassungsprüfung des Slice-Controllers gemessen. Die Gesamtzulassungszeit für Kueue-Arbeitslasten ist nicht enthalten.
  • tpu_ac_workload_processed: Zähler für Entscheidungen zur Zulassungsprüfung, der ein target_state-Label enthält.

Allgemeine Messwerte

Allgemeine Messwerte erfassen operative Probleme und Fehler:

  • tpu_ac_problem: Ein Zähler, der Betriebsprobleme oder Fehler erfasst. Dieser Messwert enthält das Label problem, das den spezifischen Fehlertyp angibt.

Bereinigen

Löschen Sie Ihre Slices, bevor Sie Knotenpools löschen, um unerwartete Kosten zu vermeiden.

  1. Löschen Sie das JobSet. Diese Aktion löst Kueue aus, um die zugehörigen benutzerdefinierten Slice-Ressourcen zu löschen.

    kubectl delete jobset JOBSET_NAME

    Ersetzen Sie JOBSET_NAME durch den Namen Ihres JobSets, z. B. big-super-slice.

  2. Löschen Sie den TPU-Knotenpool:

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

(Optional) Dynamisches Slicing mit Ihrem eigenen Planer verwenden

In diesem Dokument geht es um die Verwendung von Kueue und TAS. Sie können das dynamische Slicing aber auch mit einem eigenen benutzerdefinierten Planer verwalten. Wenn Sie einen anderen Planer verwenden möchten, folgen Sie den Referenzinformationen zur benutzerdefinierten Slice-Ressource.

Nächste Schritte